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ABSTRACT 


This  thesis  proposes  a  processor  design  for  the  Petite  Amateur  Na\7  Satellite 
(PANSAT).  The  missions  of  PANSAT  are  considered.  It  compares  the  design  of  three 
previous  satellites  with  similar  missions  and  determines  the  processor  functions  required 
to  support  PAXSAT  iiiissions.  Pariicular  attention  is  given  to  the  stoic  and  foirtard 
message  system.  A  reliable  processor  design  that  implements  these  functions  is  devel¬ 
oped.  The  reliability  of  the  proposed  design  is  examined.  Minimum  software  require¬ 
ments  for  the  resulting  design  are  listed. 
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I.  PROBLEM  DEFINITION 


A.  PURPOSE 

The  purpose  of  this  study  is  to  lay  out  the  requirements  of  the  on-board  processor 
for  the  Petite  Amateur  Nasy  Satellite.  Once  the  requirements  are  fully  established,  a 
design  will  be  specified  that  meets  the  requirements.  This  design  will  include  the  di\  ision 
of  labor  between  software  and  hardware.  Finally,  the  hardware  reliability  will  be  exam¬ 
ined. 

B.  THE  PETITE  AMATEUR  NAVY  SATELLITE 

The  Petite  Amateur  Nasy  Satellite  (PANSAT)  is  a  small,  simple,  and  inexpensive 
satellite  currently  being  designed  at  the  Nava!  Postgraduate  School.  PANSAT  is  in¬ 
tended  to  be  a  space-based  communications  experiment  that  provides  students  with 
hands-on  experience  in  satellite  design  and  operations.  It  will  accomplish  three  objec¬ 
tives.  First,  it  will  serve  as  an  educational  tool  for  NPS  students,  oflering  them  e.xperi- 
ence  in  satellite  design  and  operations.  Second,  it  will  prove  NPS  capabilitv  in  satellite 
design.  Third,  it  is  the  first  step  toward  the  Space  System  Academic  Group  s  ultimate 
goal  of  producing  the  ORION  satellite.  It  is  a  simpler  and  less  capable  satellite  than 
ORION.  Therefore,  it  can  be  produced  for  a  fraction  of  the  cost  of  the  final  version  of 
ORION.  Simplicity  and  reduced  cost  will  help  minimize  the  risks  inherent  in  a  first  de¬ 
sign.  A  tentative  launch  date  has  been  set  for  July,  1991.  [Ref.  1:  p.  1] 

1.  Background 

The  ORION  project  has  been  in  progress  for  several  years  at  NPS.  The  goal  is 
to  design  and  launch  a  small,  general  purpose  satellite  bus.  While  the  ORION  design  is 
nearly  complete,  it  has  the  disadvantage  of  being  a  complicated  and  expensive  first  at¬ 
tempt  at  satellite  design.  Before  ORION  can  be  fully  funded,  NPS  must  prove  its  capa¬ 
bility  by  designing  and  operating  a  simpler  satellite.  PAN'S.AT  is  the  vehicle  intended  to 
prove  this  capability.  P.ANSAT  will  be  less  than  half  the  size  of  ORION.  In  addition, 
although  ORION  will  be  attitude  stabilized,  PANSAT  will  have  no  attitude  control.  A 
successful  launch  and  operation  of  PANSAT  will  provide  the  ORION  project  with  the 
additional  groundwork  and  data  to  serve  as  a  baseline  on  which  to  build. 

2.  Mission 

The  primary  mission  of  PANS.AT  is  to  conduct  a  space-based  commiUnications 
experiment  which  will  provide  students  with  experience  in  design  and  operation  of  such 
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a  system.  The  desired  implementation  is  a  store  and  forward  message  system,  fhis  al¬ 
lows  an  authorized  user  to  input  a  message  while  the  satellite  is  overhead.  At  a  later 
time,  another  authorized  user  can  review  the  message  subjects  carried  by  the  satellite  and 
retrieve  those  of  interest.  Outdated  or  retrieved  messages  can  be  deleted.  Telemetry  or 
orbital  data  can  also  be  collected  on-board  and  stored  as  messages. 

In  addition,  several  secondary  missions  are  being  considered.  These  would  in- 
ciude  carrying  small  sensors  for  other  experiments  if  volumes  and  weights  permit.  Var¬ 
ious  programs  could  be  loaded  into  the  satellite  processor,  allowing  students  experience 
in  writing  software  kernels  for  satellite  control.  These  programs  could  also  be  modified 
to  monitor  memory  errors  over  time,  allowing  students  to  evaluate  effects  on  memor}’ 
circuits  from  exposure  to  increased  radiation  and  harsh  environment.  If  sensors  are  in¬ 
cluded,  power  usage  by  mentors'  and  processor  components  could  be  measured  over  time 
to  further  evaluate  exposure  effects  on  semiconductor  products.  The  more  inherent 
flexibility  available  on-board  to  reconfigure  the  processor,  the  greater  the  possibility  that 
additional  experiments  can  be  programmed  and  implemented. 

Underlying  these  experiments  is  the  primary  mission  of  educating  students  in 
space  design  and  operations.  This  goal  will  be  achieved  by  involving  students  at  all  levels 
of  design  and  operations.  Furthermore,  increased  processor  flexibility  will  maximize  op¬ 
portunities  for  student  involvement  by  permitting  additional  experiments. 

3.  PANSAT  Design 

The  following  are  working  design  constraints  that  impact  on  the  processor  sys¬ 
tem  design. 

a.  Orbit 

The  first  PANSAT  is  planned  for  launch  from  the  space  shuttle  without  any 
extra  booster.  This  constrains  the  satellite  to  a  low  earth  orbit  of  approximately  1.^0  to 
200  nautical  miles.  Actual  orbit  will  depend  on  shuttle  parameters  of  the  particular 
mission  that  launches  the  PANSAT.  Typical  orbits  have  a  90  minute  period  at  an  in¬ 
clination  of  28.5  degrees  [Ref  2:  p.  2]  The  orbit  will  also  determine  communication  op¬ 
portunities  with  the  satellite.  These  orbits  will  provide  only  one  or  two  ten-minute 
communications  windows  per  day  for  any  paiticular  ground  station. 

b.  Size 

The  Get  Away  Special  canister  size  limits  the  physical  size  of  the  satellite. 
If  a  regular  size  canister  is  used,  this  limits  satellite  size  to  approximately  19  inches  in 
length  by  19  inches  in  diameter.  Working  within  these  limits,  a  octagonal  cross  section 
design  is  planned  to  maximize  solar  collector  area.  The  planned  overall  dimensions  of 
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the  PANSAT  are  shown  in  Figure  1  on  page  4.  The  volume  within  the  satellite  allocated 
for  the  processor  is  shown  in  Figure  2  on  page  5. 

c.  Stabilization 

The  PANSAT  will  not  be  stabilized  and  will  not  have  any  station  keeping 
ability.  This  eases  requirements  on  processor  capability  because  the  processor  will  not 
be  required  to  monitor  any  attitude  sensors  or  perform  stabilization  calculations.  One 
drawback  is  the  requirement  for  multiple  antennas  to  enable  uninterrupted  communi¬ 
cation  with  the  satellite  as  it  tumbles  overhead.  The  restriction  to  omnidirectional  an¬ 
tennas  will  negatively  impact  the  communications  power  budget.  Lack  of  attitude 
control  also  implies  that  thermal  control  will  have  to  be  passive. 

d.  Communication 

Communication  with  the  PANSAT  will  be  in  the  144-146  MHz  band.  The 
type  of  communication  protocol  remains  to  be  specified.  Options  for  the  physical 
transmission  method  are  using  voice  band  transmitters  and  receivers  with  modulators 
and  demodulators  performing  the  required  analog  to  digital  conversion  or  using  a  direct 
digital  method.  The  protocol  for  controlling  transmission  is  yet  to  be  determined.  The 
data  rate  will  be  limited  to  not  more  than  9600  bits  per  second  and  will  be  in  a  serial 
format.  The  reason  for  the  9600  bps  limitation  is  two  fold.  First,  a  low  data  rate  will 
conserve  power  on  the  satellite.  Second,  it  will  allow  a  small  computer  to  be  used  as  the 
basis  for  a  ground  station. 

e.  Power 

The  satellite  will  be  powered  by  an  array  of  solar  cells  mounted  on  the  ex¬ 
terior.  These  will  charge  a  bank  of  28  two  volt,  five  amp-hour  sealed  lead-acid  batteries. 
This  will  provide  a  28  volt,  redundant  bus.  The  power  system  has  not  been  designed, 
but  initial  estimates  indicate  that  three  watts  of  continuous  power  may  be  used.  A  peak 
power  usage  of  50  watts  is  envisioned;  this  usage  will  be  sustained  only  during  the  time 
the  satellite  is  communicating  with  a  ground  station.  During  the  remaining  portion  of 
the  orbit  the  satellite  will  be  quiescent,  providing  an  opportunity  to  recharge  the  bat¬ 
teries.  [Ref  1:  p.  2] 

f.  Durability 

The  satellite  will  be  subjected  to  high  vibration  during  launch  and  orbital 
injection.  The  overall  root  mean  squared  vibration  level  is  12.9  g's  for  40  seconds  (Ref 
2:  p.  57).  The  processor  (as  well  as  the  entire  satellite)  must  be  able  to  withstand  these 
stresses  without  failure. 
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Figure  2.  PANSAT  Processor  Envelope 
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g.  Lifetime 

The  processor  must  be  able  to  function  properly  during  the  satellite's  design 
lifetime  of  one  and  one  half  years.  The  design  should  be  such  that  s}stem  failure  can 
be  avoided.  If  a  fault  occurs,  the  design  should  minimize  the  impact  on  the  mission  by 
redundancy  (appropriate  to  the  relative  simplicity  of  the  satellite)  or  by  allowing  the 
processor  to  work  around  the  fault. 

C.  PANSAT  FUNCTIONS 

The  following  functions  are  to  be  performed  by  the  satellite. 

•  Interrogation  response:  When  interrogated  by  a  specified  command  tone  (or 
combination  of  tones),  the  satellite  will  respond  (in  a  manner  to  he  determined). 

•  Orbital  store  and  forward  message  service:  The  satellite  will  be  capable  of  receiving 
messages  via  a  communications  link,  storing  the  messages,  and  transmitting  them 
upon  request. 

•  Flashing  strobe  lights  on  command:  When  a  specified  command  is  received,  the 
satellite  will  flash  externally  mounted  strobe  lights. 

The  specific  format  and  limitations  of  these  functions  are  to  be  determined  in  the 
course  of  this  design  study.  In  addition  to  the  functions  listed  above,  the  processor  must 
manage  housekeeping  functions  in  support  of  the  mission  functions.  These  support 
functions  include,  but  are  not  limiud  to: 

•  Control  of  communications  between  the  satellite  and  ground  stations,  including 
positive  control  over  the  on-board  transmitter(s). 

•  Management  of  the  mailman  message  bufi'er. 

•  Power  management  and  battery  charging,  including  sleep  and  wake  commands. 

•  Generation  and  formatting  of  status  messages. 

•  Reception,  decoding,  and  execution  of  commands  from  the  ground  control  station. 

•  Fault  detection  and  recovery. 

•  Ability  to  update  or  change  programming. 

•  Storing  telemetiy  data  in  an  on-board  buffer  (perhaps  the  store  and  forward  buffer) 
for  later  relay  to  ground  station. 

D.  ENVIRONMENT  CONSTRAINTS 

The  satellite  will  operate  in  low  earth  orbit,  imposing  certain  constraints  on  design. 
First,  the  atmosphere  will  be  close  to  vacuum.  Temperature  will  range  from  -160‘’C  to 
•+•  100°C  I  Ref  2:  p.  65].  No  active  cooling  is  envisioned  for  the  satellite.  Operating  out¬ 
side  the  protection  of  the  atmosphere  will  expose  the  satellite  to  solar  and  Van  Allen 
radiation.  Second,  power  will  be  limited  by  what  can  be  provided  by  the  solar  cells. 


6 


Third,  the  orbit  will  limit  communication  with  the  satellite  from  any  particular  ground 
station  to  approximately  10  minutes  each  pass.  Finally,  once  launched,  the  satellite  will 
be  inaccessible  for  repairs. 

E.  DESIGN  CONSTRAINTS 

The  small  size  of  the  satellite  will  impose  additional  constraints  on  the  processor 
design.  The  processor  must  have  a  small  volume  and  weight.  The  weight  constraint  is 
not  anticipated  as  a  problem  due  to  the  small  size  and  weight  of  currently  available 
processors  and  peripherals.  The  available  volume  and  footprint  for  the  processor  as¬ 
sembly  is  shown  in  Figure  2  on  page  5.  The  system  must  be  able  to  withstand  the 
stresses  of  launch  and  orbital  insertion. 

F.  DESIGN  ENHANCEMENTS 

The  following  items,  while  not  design  requirements,  are  preferred  enhancements. 
They  should  be  achieved  if  possible  within  space,  power,  weight,  and  cost  considerations. 

1.  Commonality 

The  processor  should  be  similar  to  one  commonly  available,  preferably  one  in 
current  use  at  NFS.  This  will  simplify  program  development  and  allow  increased  edu¬ 
cational  benefits.  Program  development  is  simplified  by  the  larger  number  of  software 
packages  (specifically  compilers  and  assemblers) 'available  for  a  common  processor.  It 
is  very  desirable  that  the  processor  chosen  have  available  high  level  language  compilers 
to  allow  programming  the  processor  in  C  or  an  equivalent  language.  The  educational 
benefit  is  enhanced  by  allowing  students  to  develop  a  program  on  a  ground-based  com¬ 
puter.  Once  debugged  and  verified  it  can  be  uploaded  and  tested  on  an  actual  satellite. 

2.  Upwardly  compatible 

The  processor  should  have  enough  capability  to  expand  easily  to  meet  the  ad¬ 
ditional  computing  requirements  of  ORION.  These  will  include  the  capability  to  su¬ 
pervise  the  attitude  control  of  the  enhanced  version.  The  processor  will  also  have  to 
manage  communications  with  an  on-board  experiment,  either  by  formatting  and  passing 
messages,  or  by  exerting  direct  control  over  the  experiment.  ORION  may  carry  a  system 
to  relay  video  images  to  a  ground  station.  This  implies  a  higher  data  rate  on  the  ORION 
communication  link  than  on  the  PANSAT  communication  link.  A  solid  state  bubble 
memory  recorder  is  a  candidate  processor  that  will  require  interfacing  with  the  processor. 
The  PANSAT  processor  should  have  a  growth  margin  to  meet  these  future  needs  of 
ORION.  In  addition,  if  a  single  processor  design  is  used  it  should  be  easily  upgradable 
to  a  multiple  processor  configuration  for  these  future  requirements. 
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3.  Real  time  clock 

A  real  time  clock  accessible  through  the  processor  is  a  possible  enhancement. 
This  would  allow  processor  events  to  be  scheduled  for  a  specific  time. 

G.  RESEARCH  QUESTIONS 

The  research  questions  for  this  study  may  be  identified  as: 

•  What  computing  power  is  required? 

•  What  processor(s)  will  meet  this  requirement? 

Should  the  approach  be  a  microcontroller  giving  a  potential  single-chip  design, 
or  would  a  microprocessor  design  be  more  appropriate  (with  the  larger  chipset  and 
footprint  implied)? 

•  What  will  be  the  layout  of  the  system? 

Single  processor  versus  multiprocessor.  If  multiple  processors  are  used,  should 
the  system  be  tightly  coupled  or  loosely  coupled. 

•  What  is  the  proper  division  of  tasks  between  software  and  hardware? 

•  How  will  the  computer  system  interface  to; 

1.  Power  system,  including  batteries  and  solar  cells? 

2.  Communications  system. 

3.  Strobe  lights. 

4.  Any  other  on-board  sensors. 

•  What  size  of  R.AM  and  ROM  is  required. 

•  What  amount  of  radiation  hardening  is  required? 

•  What  additional  hardware  (especially  RAM)  is  required  to  support  the  store  and 
forward  function.  Does  this  have  a  lower  reliability  standard? 

•  What  amount  (if  any)  of  security  must  be  provided  to  prevent  unauthorized  control 
of  the  satellite? 

•  How  will  communications  with  the  satellite  be  handled?  Will  all  communications 
go  through  the  processor,  or  will  there  be  a  dedicated  telemetr\'  and  comntand  link? 
Will  a  custom  communications  protocol  be  used,  or  will  a  standard  method  be 
adopted? 

Specific  software  development  will  not  be  addressed  beyond  what  is  required  to  en¬ 
sure  that  the  required  functions  will  in  fact  be  programmable  (with  a  given  margin  for 
growih)  within  the  hardware  that  is  developed. 

H.  CANDIDATE  PROCESSORS 

The  processor  upon  which  the  system  is  based  should  be  commercially  available  in 
a  low  power,  radiation  hardened  version.  The  following  processors  are  candidates  for 
consideration; 
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•  8085  or  equivalent  8  bit  microprocessor. 

•  8086  or  equivalent  16  bit  microprocessor. 

•  Z80,  Z280  or  NSC  800  8  bit  microprocessor. 

•  MC68000  16  bit  microprocessor. 

•  .MC68HC11  microcontroller. 

•  8096  microcontroller. 

I.  COMMUNICATIONS  PROTOCOLS 

The  protocol  used  for  communicating  between  the  satellite  and  a  ground  station  will 
impact  on  processor  design.  The  first  question  is  what  protocol  to  use.  Either  a  stand¬ 
ard  protocol,  such  as  X.25,  or  a  custom-designed  protocol  may  be  implemented.  If  a 
custom  protocol  is  required,  the  error  detection  methods  must  be  specified.  If  a  standard 
communications  protocol  is  to  be  used,  what  amount  of  computing  must  the  software 
do  and  what  amount  will  be  done  in  specialized  hardware?  When  referring  to  the  seven 
layer  ISO  model  for  computer  communication  (see  Table  1),  which  layers  are  handled 
in  software  and  which  in  hardware?  The  physical  layer,  which  includes  the  communi¬ 
cations  equipment,  is  implemented  in  hardware.  The  second  and  third  layers  may  be 
implemented  in  either  software  or  hardware.  Levels  four  and  above  are  typically  software 
based,  and  may  not  all  be  needed.  Elimination  of  higher  levels  will  simplify  software 
requirements,  and  therefore  hardware  requirements,  on  the  satellite. 


Table  1,  ISO  SEVEN  LAYER  MODEL 


Highest  level 

7. 

Application  layer 

6. 

Presentation  layer 

5. 

Session  layer 

4. 

Transport  layer 

3. 

Network  layer 

2. 

Link  layer 

Lowest  level 

1. 

Physical  layer 

J.  DESIGN  SCOPE 

The  conceptual  design  breakdown  of  PANSAT  is  shown  in  Figure  3  on  page  10. 
The  processor  is  a  central  portion  of  the  design  as  it  interfaces  with  all  other  systems. 
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This  design  concentrates  on  the  block  labeled  hardware  design.  Since  most  other  areas 
are  still  conceptual,  assumptions  are  made  and  dclendcd  where  necessary. 


Figure  3.  PANSAT  conceptual  design 
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II.  SYSTEM  REQUIREMENTS  ANALYSIS 
A.  PREVIOUS  DESIGNS 

Many  amateur  satellites  have  been  constructed  over  the  years.  These  designs  are 
an  important  starting  place  because  the  capability  is  similar  to  that  desired  for  PAXSAT. 
Three  designs  are  of  special  interest.  These  are  the  L'oSAT-2,  UoSAT-D,  and  FO-12 
satellites.  Pertinent  design  features  of  the  processors  on  these  satellites  are  summarized 
in  Table  2. 


Table  2.  SATELLITE  PROCESSOR  SUMMARY 


Satellite 

L'oSAT-2  (Oscar-11) 

FO-12  (Oscar-12) 

UoSAT-D 

Purpose 

digital  comm  exper¬ 
iment 

orbital  mailman 

orbital  mailman 

Processor 

NSC-SOO  (Z-80) 

NSC-SOO  (Z-80) 

S0C186 

3  cards  6"x9"xr' 

10  cards  6.3"x5.91" 

329  ICs 

0.9  MHz 

1.7  MHz 

8  MHz 

Comms 

MSG-2 

AX.25 

AX.25 

UARTs 

discrete  HDLC  con¬ 
troller  3  cards 
6.85"x8.74"  144  ICs 

4  uplink  1  downlink 

1200  bps 

1200  bps 

9600  bps 

Power 

1  watt 

3.5  watts 

(not  given) 

.VIemor>' 

126  kbyte  static  RAM 

1  Mbvte  dvnamic 

R.AM' 

4  Mbytes 

512  bytes  PROM  (re¬ 
dundant),  16  kbytes 
of  R.AM  have  one  bit 
EDAC 

(No  SRAM  or 

PROM),  32  kbytes 
kernel,  stack,  and 
static,  4  x  256  kbyte 
cards  bank  switched, 

1  bit  EDAC 

Attitude 

control 

gravity  boom,  active 
magnets 

spin,  passive  magnets, 
lossy  dampers 

gravity  boom,  active 
magnets 
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1.  UoSAT-2 

THe  UoSAT-2  was  designed  as  a  digital  communications  experiment  to  prove 
technology  to  be  used  in  follow-on  satellites.  It  utilized  a  NSC-SOO  processor  (similar  to 
a  Z-SO)  running  at  0.9  MHz.  The  communications  link  operated  at  1200  bits  per  second 
utilizing  a  custom  message  protocol.  This  custom  protocol,  MSG2.  was  used  due  to  lack 
(in  1985-86)  of  a  low  power  CMOS  HDLC  controller  chip  or  room  for  a  discrete  HDLC 
implementation.  This  protocol  is  byte  oriented.  The  MSG2  frame  format  is  shown  in 
Figure  4.  Byte  stuffing  is  used  to  ensure  the  frame  marker,  [10h][03h].  does  not  occur 
within  the  frame.  When  [lOh]  is  to  be  transmitted,  it  is  changed  to  [10h][10h],  then  re¬ 
converted  aft^'r  ’■cception.  The  kernel  implementing  MSG2  was  written  in  Z-SO  assem¬ 
bler  code  and  occupies  2.5  kilobytes  of  error  detection  and  correction  protected  (ED.AC) 
R,AM.  Ground  stations  must  have  a  custom  software  package  to  communicate  with  this 
satellite.  [Ref  3] 

[10h][03h]  <con'imand>  <commandnot>  <datalength>  (data)  <<CRC>> 

<  >  indicates  byte  data 

<  <  >  >  indicates  16  bit  data 

(  )  indicates  variable  length,  defined  by  data  length  byte 


Figure  4.  MSG2  protocol  frame  format 


There  are  several  ideas  used  in  the  L'oS.AT-2  that  may  be  applicable  to  the 
PANSAT  design.  These  are: 

•  Successful  use  of  commercial  grade  RAM  chips  in  a  low  earth  orbit  environment. 

•  Error  detection  on  vital  RA.M  (non-vital  RA.M  does  not  have  error  detection). 

•  Whole  orbit  telemetrv'  monitoring  using  message  RAM  to  store  data  for  downlink 
while  satellite  is  overhead. 

2.  UoSAT-D 

The  UoSAT-D  satellite  is  a  packet  communications  experiment  that  builds  on 
UoSAT-2.  UoSAT-D  implements  the  AX. 25  packet  radio  protocol  operating  at  9600 
bits  per  second  in  full  duplex  mode.  It  utilizes  a  80C186  processor  operating  at  8  MHz. 
This  processor  has  sufficient  processing  capacity  to  handle  all  the  satellite's  internal 
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housekeeping  concurrent  with  packet  radio  operation.  UoSAT  has  developed  software 
for  the  ground  stations  that  is  available  if  the  AX. 25  protocol  is  adopted.  [Ref  4) 

3.  FO-12 

The  FO-12  satellite  is  a  store  and  forward  digital  mailbox.  It  implements  the 
AX. 25  protocol  with  four  uplink  channels  and  one  dowmlink  channel,  all  operating  at 
1200  bits  per  second.  The  AX. 25  protocol  was  implemented  in  discrete  CMOS  logic.  No 
ROM  was  used  in  FO-12.  Initial  program  load  was  accomplished  via  hard-wired  logic. 
[Ref  5] 

B.  RADIATION  EFFECTS  ON  CMOS  DEVICES 

The  processor  for  PANS.AT  will  be  constructed  mostly  from  complementary  metal 
oxide  semiconductor  (CMOS)  integrated  circuits.  The  advantage  of  C.MOS  is  the  ex¬ 
tremely  low  power  consumption  exhibited  by  these  devices.  Low  power  consumption 
also  implies  reduced  generation  of  excess  heat,  an  important  consideration  in  a  satellite 
with  only  passive  thermal  control.  In  addition,  power  consumption  can  be  controlled 
by  regulating  the  frequency  of  operation.  (Lower  speeds  require  lower  power.)  However, 
CMOS  circuits  can  be  adversely  affected  by  radiation  in  the  space  environment. 

The  interaction  of  particles  and  energies  can  actually  be  broken  down  into  two  main 
mechanisms  which  dominate  the  elfect  of  radiation  in  materials  in  which  we  are 
concerned:  1.  Displacement  of  atoms  from  their  lattice  structure  (displacement 
damage).  2.  Generation  of  electron-hole  pairs  (ionization).  Both  effects  can  cause 
temporar}'  (transient)  or  permanent  damage  to  semiconductors.  (Ref  6:  p.  2-5] 

Radiation  hardened  circuits  are  designed  to  minimize  the  long  term  effects  of  radiation. 
However,  this  hardening  makes  the  circuits  much  more  expensive  than  equivalent  in¬ 
dustrial  quality  devices.  Memory  devices  are  especially  affected  by  increased  cost.  Since 
radiation  damage  occurs  over  time,  it  may  be  possible  to  use  a  mixture  of  industrial 
quality  and  radiation  hardened  components  to  meet  the  lifetime  requirement  for 
PANSAT. 

A  second  type  of  disturbance  occurs  specifically  in  memory  devices.  A  high  speed 
particle  may  traverse  through  the  semiconductor  leaving  an  ionized  path.  This  ionization 
may  be  sufficient  to  cause  a  static  inverter  to  change  state,  or  a  dynamic  storage  element 
to  lose  charge.  In  the  worst  case,  the  panicle  will  leave  an  ionization  path  through  to 
the  substrate  and  cause  latch-up.  Either  process  will  cause  corruption  of  at  least  one  bit 
of  memory.  Latch-up  will  result  in  increased  current  draw  and  will  require  removing 
power  from  the  circuit  to  reset  the  condition.  Temporarv'  loss  of  a  bit,  while  corrupting 
the  stored  value,  can  be  remedied  by  rewTiting  the  affected  word.  When  the  disturbance 
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is  temporary  and  can  be  remedied  by  rewriting  the  afTected  value,  it  is  termed  a  single 
event  upset  (SEU).  Like  permanent  damage  effects,  SEUs  can  be  reduced  by  using  ra¬ 
diation  hardened  memory  devices.  While  the  physical  process  that  causes  these  events 
is  known, 

...prediction  and  simulation  of  the  SEE'  rate  for  a  given  satellite  in  a  given  orbit  are 
veiy  inaccurate.  The  SEU  rate  depends  on:  memoiy  device  manufacturing  technique, 
device  geometiy,  shielding,  satellite  orbit,  satellite  attitude,  solar  activity,  (and) 
geomagnetic  activity.  [Ref  3] 

The  UoSAT-2  experiment  experienced  21  SEUs  in  a  period  of  185  days  in  144  kilobits 
of  industrial  quality  memory.  The  equivalent  shielding  of  the  memory  was  not  specified. 
Since  the  orbit  of  PANSA  f  will  be  lower  than  UoSAT-2,  SEU  rates  will  probably  be 
lower,  reducing  the  requirement  for  error  detection  and  correction.  [Ref  3] 

C.  INTEGRATED  CIRCUIT  SCREENING  LEVELS 

Device  screening  and  qualification  varies  depending  on  the  manufacturer.  Specific 
quality  requirements  for  government  applications  are  established  in  M I L-S 10-883  and 
MlL-M-38510.  These  standards  establish  quality  requirements  for  militaiy  Class  B, 
Class  S,  and  radiation  hardened  devices.  Class  B  qualification  is  required  for  devices  used 
in  typical  militaiy  applications.  Class  B  screening  includes  a  100" o  burn-in  test  at 
+  125°C  to  weed  out  potentially  defective  items.  Class  S  qualification  places  the  most 
stringent  requirements  on  the  devices.  Testing  begins  with  wafer  lot  acceptance.  All 
devices  are  subjected  to  a  bond  pull  test  where  each  connecting  wire  from  the  die  to  the 
package  is  tested  to  ensure  that  it  will  not  detach.  These  devices  arc  individually  serial¬ 
ized.  The  circuit  is  burned-in  at  +  125'’C  for  240  hours,  then  reverse  biased  at  +  150°C 
for  72  hours.  Other  statistical  and  electrical  checks  are  performed,  ending  with  two  sep¬ 
arate  x-ray  views  of  the  device.  Due  to  the  stringent  test  requirements  of  Class  S  quali¬ 
fication.  few  devices  survive  screening.  This  makes  the  cost  of  Class  S  devices 
considerably  higher  than  devices  tested  to  lower  standards.  In  addition,  few  manufac¬ 
turers  perform  Class  S  screening;  this  screening  is  typically  on  a  custom  order  basis. 
Manufacturers  often  provide  Class  B  or  Class  S  look  alikes.'  These  devices  follow  a  flow 
that  is  similar  to  MIL-STD-883  but  may  be  obtained  at  a  lower  cost.  The  basic  screening 
levels  are  summarized  in  Table  3  on  page  15.  (Ref  6:  pp.  13-8  to  14-21] 

In  following  sections,  high  reliability  devices  will  indicate  those  that  meet  the  JAN 
Class  B  screening.  Radiation  hardened  will  indicate  devices  that  are  certified  with 
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MIL-STD-SS3  Group  E  radiation  hardness  assurance  tests  in  addition  to  the  Class  B 


screening. 


Table  3.  DEVICE  SCREENING  LEVELS 


Level 

Temperature 
range  (‘'C) 

Screening  includes: 

Represen¬ 
tative  cost 
(S0S6) 

commercial 

0  to  +  70 

statistical 

S22 

industrial 

-40  to  -t-  85 

statistical,  may  require  burn-in 

S38 

military  (High  reli- 
abilitv,  JAN  class 

B) 

-55  to  -t-  125 

lOC  o  testing,  burn-in  160 
hours  at  +  125°C 

S261 

radiation  hardened 

Samples  from  each  wafer  sub¬ 
jected  to  radiation  tests 

SSOO 

military  (space 
qualified,  J.AN 
class  S) 

-55  to  -1-125 

lOO'N  serialization  and  ex¬ 
haustive  testing,  burn-in  240 
hours  at  +  125°.  x-ray  after 
burn-in. 

greater 
than  S2000 
for  Class  S 
look-alike 

D.  DESIGN  INTERFACES 

The  P.ANS.AT  processor  will  interface  with  all  satellite  systems.  The  major  subsys¬ 
tems  are: 

•  Communications  system 

•  Power  supply  and  battery  charging  system 

•  Experiments 

•  Structural  system 

In  addition,  the  processor  hardware  will  interact  with  the  processor  software  to  accom¬ 
plish  assigned  tasks.  At  present,  only  the  PANSAT  structural  system  has  been  designed. 
Since  the  other  systems  are  not  yet  designed,  this  design  will  make  educated  assumptions 
about  these  other  systems  and  required  interfaces.  These  assumptions  may  prove  incor¬ 
rect  in  the  long  term,  but  they  provide  a  starting  place  for  the  processor  design. 


E.  PROCESSING  POWER 

The  processing  power  required  in  PANSAT  is  dependent  upon  the  tasks  assigned  to 
the  processor.  These  tasks  can  he  divided  into  four  categories: 
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•  communications 

•  housekeeping 

•  telemetry 

•  command  execution 

The  communication  task  will  consume  most  of  the  processor  capability  so  it  was  inves¬ 
tigated  first. 

1.  Communications 

a.  Number  of  communication  links 

Previous  satellites  designed  to  accomplish  a  mission  similar  to  PANSAT 
have  used  at  least  two  communication  links.  One  link  is  a  specialized  channel  to  transmit 
commands  to  the  satellite  and  receive  telemetry  data  from  the  satellite.  The  second 
channel  (in  some  cases  several  channels)  implements  the  digital  store  and  forward  mes¬ 
sage  system.  .Many  users  have  access  to  the  store  and  forward  channel  operating  in  a 
known  format.  Only  the  ground  control  stations  know  the  correct  format  and  frequen¬ 
cies  for  the  command  channel.  The  digital  message  channel  can  also  be  used  by  the 
controlling  station  to  upload  revised  programming.  Use  of  more  than  one  channel  gives 
the  satellite  redundancy.  If  the  command  channel  fails,  the  message  channel  can  be  used 
to  send  commands  to  the  satellite.  Telemetry'  can  be  sent  either  over  the  dedicated 
channel,  or  can  be  collected  by  the  processor,  formatted,  then  sent  over  the  digital 
communication  channel.  The  disadvantage  of  this  approach  is  that  two  separate 
transceivers  must  be  located  in  the  satellite.  The  size  of  PANSAT  precludes  using  two 
transceivers.  Restriction  to  a  single  communications  link  requires  this  link  to  accomplish 
all  functions. 

Use  of  a  single  communications  link  makes  the  hardware  design  of  the 
processor  simpler.  The  tradeoff  will  be  in  the  software  which  must  become  more  complex 
to  handle  the  following  tasks  over  the  single  channel: 

•  Command  uplink,  including  satellite  reprogramming. 

•  Telemetry  downlink. 

•  Store  and  forward  message  system. 

•  Hardware  reset  to  restart  system  on  program  malfunction. 

The  link  must  then  be  designed  to  embed  the  commands  in  the  store  and  forward  mes¬ 
sage  format.  Telemetry  downlink  will  be  placed  into  the  message  buffer  and  received  as 
a  forwarded  message.  Since  a  single  link  will  be  used  which  is  accessible  to  amateur 
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radio  operators,  a  security  system  is  required  in  software  to  prevent  an  unauthorized  user 
from  reprogramming  the  satellite  or  inadvertently  sending  the  reset  sequence. 

This  assumption  of  a  single  link  is  the  most  restrictive  case.  When  the 
communications  system  is  designed,  it  may  prove  possible  to  multiplex  the  digital  link 
and  a  separate  command  link.  If  this  is  possible,  this  design  will  still  be  valid,  with  the 
separate  link  adding  redundancy. 

b.  Communications  protocol 

The  options  for  a  communication  protocol  are  to  design  a  custom  protocol 
or  to  use  a  standard  protocol.  The  advantages  of  a  custom  protocol  are  that  the  capa¬ 
bilities  of  the  specific  satellite  can  be  maximized.  However,  the  disadvantages  of  using 
an  unproven  protocol,  which  include  requiring  a  custom  software  implementation  for 
both  ground  stations  and  the  satellite,  outweigh  any  possible  benefit.  Additionally,  if  a 
custom  protocol  is  used,  this  will  limit  satellite  accessibility  to  amateur  radio  opera'  ars. 

AX. 25  and  .VlSGd  are  the  two  probable  choices  for  a  standard  protocol. 
MSG2  was  illustrated  previously  in  Figure  4  on  page  12.  AX. 25  is  an  extension  of  the 
standard  X.25  data  link  control  protocol.  AX. 25  extends  the  address  field  to  allow  en¬ 
coding  of  amateur  radio  operator  callsigns.  Callsigns  of  up  to  six  letters  (one  letter  per 
byte,  with  an  additional  byte  for  secondary  station  identifier)  are  included  for  both 
sender  and  receiver.  Up  to  eight  repeater  stations  may  be  used,  extending  the  address 
field  to  512  bytes.  The  X.25  and  AX. 25  formats  are  shown  in  Figure  5  on  page  IS. 
.AX. 25  is  a  bit  oriented  protocol.  The  flag  '011111 10'  is  used  to  signal  the  beginning  and 
end  of  a  frame.  The  flag  is  prevented  from  occurring  within  the  frame  by  inserting  a  '0' 
after  any  sequence  of  '11111.'  This  process,  called  bit  stuffing,  is  compensated  by  the 
receiving  station  removing  any  '0'  after  a  sequence  of  11111.'  [Ref  7:  pp.  1-9] 

The  diilerences  between  MSG2  and  AX. 25  are  summarized  in  Table  4  on 
page  19.  Significant  differences  are  the  type  of  automatic  repeat  request  (ARQ).  infor¬ 
mation  frame  length,  and  orientation  (bit  versus  byte  oriented).  The  ARQ  and  frame 
length  differences  combine  to  determine  maximum  possible  throughput.  Processing 
power  required  is  affected  by  whether  the  format  is  bit  or  byte  oriented. 

To  compare  maximum  theoretical  throughput,  the  distance  to  the  satellite 
must  be  determined.  Assuming  the  satellite  is  orbiting  370  kilometers  above  the  earth 
(H),  using  6378  kilometers  as  an  average  earth  radius  (Re),  and  presuming  the  satellite 
elevation  (E)  must  be  above  ten  degrees  for  successful  communication,  the  slant  range 
to  the  satellite  (d)  is  given  by:  (Ref  8:  p.  45] 
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Figure  5.  X.25  and  AX.25  Data  Link  Control  Protocols 


IS 


Table  4.  COMPARISON  OF  MSG2  AND  AX.25 


Protocol 

MSG2 

AX.25 

Orientation 

b}  te  serial 

bit  serial 

ARQ 

selective  repeat 

go  back  N 

1  frame  length 

up  to  64  bytes 

up  to  256  bytes  {*) 

Overhead 

7  bytes 

20  to  76  bytes 

*  Some  implementations  may  have  a  lower  limit 

=  (/?e  + //)^  + + //)  X  sin[£  +  sin  ’(  cos  £)]  (1) 

This  gives  a  value  of  1359  km  for  the  maximum  slant  range.  The  minimum  slant  range 
will  occur  if  the  satellite  is  directly  overhead  at  370  km.  Most  communication  will  be 
done  at  a  value  between  these  two  extremes.  Since  the  satellite  will  rarely  pass  directly 
overhead,  a  nominal  communication  range  of  1000  km  will  be  assumed  to  compare 
throughput  for  the  AX.25  and  MSG2  formats. 

AX.25  uses  go  back  N  format,  where  N  is  eight.  The  throughput,  p.  for  this 
format  is  given  by.  [Ref.  9:  p.  222.] 


P  = 


I  -  P 


1  + 


2Tp_ 

Tf 


P 


•  P  is  the  frame  error  probability;  P  =  1  —  (I  —  Pb)^'’ 

•  Pb  is  the  probability  a  single  bit  is  in  error. 

•  .\b  is  the  number  of  bits  in  a  frame. 

•  77  is  the  time  required  for  transmission  of  a  frame. 

•  Tp  is  the  propagation  and  processing  delay. 


(2) 


MSG2  is  a  selective  repeat  format.  The  throughput  for  selective  repeat  is  given  by:  (Ref 
9:  p.  233] 


p  =  \  —  P 


(3) 


where  P  is  given  above. 
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A  minimal  AX. 25  frame  will  have  20  b>'tes  of  overhead.  Assuming  a  ten 
percent  overhead,  this  give  an  I  frame  size  of  200  bytes,  or  1600  bits.  This  overhead  is 
similar  to  a  71  byte  MSG2  frame,  which  has  7  bytes  of  overhead.  The  throughputs  for 
these  protocols  are  compared  in  Figure  6  on  page  21  using  these  assumptions.  As  bit 
error  rate  increases,  throughput  drops  more  rapidly  for  AX. 25  than  for  MSG2.  Most  of 
this  difference  comes  not  from  protocol  differences,  but  from  the  frame  size  effect  on 
frame  error  probability.  The  frame  error  probability  for  AX. 25  could  be  reduced  by  de¬ 
creasing  frame  size.  This  would  increase  the  fraction  of  overhead  since  the  20  byte 
overhead  cannot  be  avoided.  In  a  frame  addressed  through  repeaters,  overhead  could 
increase  to  as  much  as  76  bytes.  As  long  as  single  bit  error  probability  remains  below 
3  X  10“^  ,  throughput  for  AX. 25  is  acceptable.  This  requirement  to  maintain  low  bit  er¬ 
ror  rate  must  be  included  in  the  design  of  the  communication  package  for  PANS.^T. 

MSG2  is  a  byte  oriented  protocol.  The  processor  does  not  require  any  ad¬ 
ditional  hardware  or  special  algorithms  to  implement  the  protocol.  All  that  is  necessary 
is  to  examine  the  byte  stream  for  the  byte  [lOh].  This  can  be  done  by  a  simple  compar¬ 
ison.  In  contrast,  AX. 25  is  a  bit  oriented  protocol.  The  flag  OlllIIlO'  can  occur  any¬ 
where  in  the  bit  stream,  not  just  as  a  byte.  This  means  that  the  entire  bit  sequence  must 
be  examined  to  detect  any  sequence  of 'HUT  which  must  then  be  stuffed  to  prevent  the 
flag  from  occurring  within  the  frame.  This  requires  either  a  dedicated  data  link  control 
(DLC)  protocol  hardware  device  or  complicated  software  algorithms. 

Although  AX. 25  has  a  lower  throughput  than  MSG2  and  will  be  more 
complicated  to  implement,  this  is  the  protocol  that  will  be  implemented  on  PANSAT. 
This  protocol  is  the  current  standard  used  for  communication  with  amateur  satellites. 
If  this  protocol  is  used,  ground  station  testing  can  be  conducted  with  amateur  satellites 
presently  in  orbit.  In  addition,  once  PANSAT  is  in  operation,  other  amateur  ground 
stations  will  be  able  to  access  PANSAT's  store  and  forward  message  system. 

The  processor  must  be  able  to  perform  the  bit  stream  formatting  required 
in  AX.25.  The  communication  link  must  be  designed  to  maintain  a  bit  error  rate  that 
does  not  adversely  affect  traffic  throughput. 

c.  Implementation  of  AX.25  communications  protocol 

The  communications  protocol  can  be  implemented  either  in  software  or  by 
dedicated  hardware  support.  A  software  implementation  of  AX.25  will  not  be  consid¬ 
ered.  Although  it  is  theoretically  possible  to  implement,  the  task  of  examining  the 
bitstream  bit  by  bit  and  computing  the  CRC  checksum  for  both  an  incoming  and 
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outgoing  channel  at  9600  bps  will  severely  task  the  software  designer.  Software 
implementation  will  only  be  considered  if  a  hardware  solution  pro\  es  unfeasible. 

If  a  hardware  implementation  is  used,  the  designer  typically  has  three  dif¬ 
ferent  methods  of  controlling  the  hardware  protocol  chip.  These  are; 

•  polled 

•  interrupt  driven 

•  direct  memory  access 

In  a  polled  system,  the  processor  must  regularly  interrogate  the  protocol  chip  to  deter¬ 
mine  if  the  chip  is  ready  for  input  or  output.  In  an  interrupt  configuration,  the  chip  will 
interrupt  the  processor  when  it  requires  data  transfer.  In  a  direct  memory  access  system, 
the  processor  stores  the  data  parameters  in  the  DMA  controller  and  then  initializes  the 
chip.  The  data  transfer  then  takes  place  with  no  further  intervention  from  the  processor. 
The  DMA  processor  will  then  inform  the  processor  when  the  transfer  is  complete. 

The  polled  system  is  the  easiest  to  implement  and  requires  little  additional 
circuitiy  to  perform.  The  disadvantage  is  that  additional  software  complexity  is  required 
to  allow  the  processor  to  accomplish  other  tasks  while  waiting  to  transfer  data  to  the 
protocol  chip.  The  DMA  arrangement  allows  higher  transfer  rates  as  the  processor  is 
not  involved  in  transfers.  The  DMA  controller  'steals'  cycles  from  the  processor  to 
transfer  data  without  requiring  processor  intervention  other  than  to  temporarily  relin¬ 
quish  the  system  bus.  However,  the  DMA  controller  implies  additional  circuitry  not 
required  by  the  other  implementations.  In  addition,  the  DM.4  controller  is  not  available 
in  a  radiation  hardened  version. 

PANSAT  requires  an  interrupt  controller  for  several  functions  detailed  in 
following  sections.  Therefore  using  an  interrupt  structure  to  service  the  hardware  pro¬ 
tocol  chip  will  not  add  to  circuit  complexity.  Table  5  on  page  23  shows  a  possible  in¬ 
terrupt  service  routine  used  to  provide  data  from  a  8086  processor  to  a  8273  HDLC 
protocol  controller.  Assuming  the  processor  operates  at  5  MHz  (with  no  wait  states) 
then  163  clock  cycles  equates  to  32.6  microseconds.  At  9600  bits  per  second,  the 
processor  needs  to  process  1200  bytes  per  second,  or  one  byte  every  833.3  microseconds. 
In  full  duplex  mode,  there  is  one  incoming  byte  and  one  outgoing  byte  every  833.3 
microseconds,  each  taking  32.6  microseconds.  The  fraction  of  available  processor  time 
used  for  HDLC  control  is  0.078.  Thus  using  the  processor  to  operate  the 
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communications  link  on  a  byte  by  byte  interrupt  basis  only  requires  about  8  percent  of 
available  processor  time. 


Table  5.  8086  INTERRUPT  ROUTINE  TO  SERVICE  8273 


Instruction 

Clock 

cycles 

Comment 

complete  current  instruction 

10 

(assumed  average,  not  included  in 
total) 

Interrupt  processing 

61 

push  CS,  IP,  FLAGS,  get  inter¬ 
rupt  vector,  and  branch  to  service 
routine 

PUSH  AX 

11 

save  register 

PUSH  BX 

11 

MOVE  AL.ISI] 

S  +  EA=  14 

get  next  byte 

OUT  =HDLCOUT.AU 

10 

output  to  8273 

INC  SI 

2 

point  to  next  item 

MOVE  iRSTlNT.AL 

4 

OUT  ??INTPROC.AU 

10 

reset  interrupt  controller 

POP  BX 

s 

restore  registers 

POP  AX 

s 

IRET 

24 

Total: 

163 

d.  Higher  layer  protocols. 

Although  AX. 25  has  been  selected  for  use,  this  is  only  the  second  layer 
protocol.  This  will  transmit  error  free  packets  between  the  satellite  and  a  groundstation. 
Higher  level  interfaces  are  required  to  reassemble  these  packets  into  complete  messages. 
These  higher  level  protocols  must  also  determine  what  action  to  take  with  the  message. 
These  actions  may  include: 

•  add  message  to  the  buffer, 

•  retrieve  message  from  the  buffer, 

•  list  buffer  messages, 

•  issue  satellite  command  or  load  a  program,  and 

•  transmit  telemetry^  data. 
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These  commands  are  a  function  of  the  software,  not  the  hardware  implementation,  and 
will  not  be  considered  further.  (Higher  layer  software  for  the  satellite  and  ground 
stations  may  be  available  from  AM  SAT.) 
e.  Transmitter  control 

A  major  concern  for  getting  the  PANSAT  design  approved  for  launch  is 
demonstrating  positive  control  over  the  transmitter.  If  the  satellite  has  a  malfunction, 
there  must  still  exist  means  to  secure  the  transmitter  from  the  groundstation.  Legally, 
telecommand  capability  is  necessaiy: 

...to  turn  off  a  malfunctioning  transmitter  that  might  conceivably  cause  harmful  in¬ 
terference  to  important  radio  services  worldwide.  [Ref  10  :  p.  12-2] 

The  processor  can  be  configured  to  provide  positive  control  over  the  transmitter.  How¬ 
ever,  if  a  failure  occurs  and  the  processor  is  no  longer  operating,  this  control  will  not  be 
sufficient.  A  method  must  e.xist  to  secure  the  transmitter  that  does  not  presume  the 
processor  or  HDLC  hardware  is  operating.  This  method  will  be  a  function  of  the  com¬ 
munication  package.  A  unique  sequence  that  would  not  normally  be  encountered  could 
be  assigned  as  a  reset  sequence.  A  sequence  detector  could  be  included  in  the  transceiver 
to  detect  this  sequence  and  secure  the  transmitter  independently  of  the  processor.  This 
sequence  mu' t  consider  that  transmitters  may  continuously  send  flags  while  idle  and  that 
a  sequence  of  15  T's  is  used  as  a  frame  abort  sequence.  Responsibility  for  further  de¬ 
velopment  of  the  processor  failed  transmitter  control  will  be  left  to  the  communication 
package  designer.  A  method  to  secure  the  transmitter  on  failure  of  the  receiver  will  be 
discussed  in  a  following  section. 

2.  Telemetry  and  commands 

The  processor  will  be  responsible  for  receiving  commands  over  the  digital  link 
and  executing  these  commands.  In  addition,  the  processor  will  monitor  on-board  sen¬ 
sors,  collecting  and  formatting  telemetry  messages.  Command  execution  is  mostly  a 
function  of  the  software.  The  software  must  be  designed  to  recognize  that  an  incoming 
packet  is  a  command  to  the  satellite  instead  of  a  store  and  forw'ard  message.  The  soft¬ 
ware  must  implement  security  to  ensure  that  only  authorized  stations  can  command 
satellite  functions.  The  hardware  interface  will  be  a  parallel  output  port  that  can  com¬ 
mand  relay  drivers.  Depending  on  the  number  of  actuators  to  be  driven,  a  multiplexer 
may  also  be  required. 

Telemetr}'  data  will  be  gathered  through  an  analog  multiplexer  and  analog  to 
digital  converter.  Some  telemetiy  data  concerning  the  communications  package  or  the 
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embarked  experiment  may  be  sampled  in  a  digital  format.  Again,  it  will  be  a  function 
of  the  software  to  perform  data  collection  and  to  format  the  data  into  packets  for 
transmission.  The  number  of  input  channels  for  telemetry  and  output  channels  for 
command  actuation  is  yet  to  be  determined. 

Processing  power  required  for  telemetry'  gathering  is  minimal.  The  processor 
needs  only  to  select  a  multiplexer  address,  start  analog  to  digital  conversion,  and  read 
the  results  when  the  conversion  is  complete.  Even  if  64  channels  of  data  (a  large  number 
for  such  a  small  satellite)  are  required  to  be  sampled  every  five  seconds,  actual  processor 
cycles  required  would  be  a  small  fraction  of  available  cycles.  Command  execution  is 
even  easier.  All  that  will  be  necessary  is  to  output  a  bit  or  word  to  a  parallel  port  to 
actuate  a  relay  driver.  (No  capability  for  analog  output  is  envisioned.) 

3.  Housekeeping 

At  present,  the  only  housekeeping  functions  anticipated  are  control  and  moni¬ 
toring  of  the  battery  charging  system.  The  power  system  for  the  satellite  has  not  been 
designed  at  present  beyond  specifying  redundant  28  volt  battciy  banks.  Each  bank  may 
require  means  to  independently  connect  or  disconnect  the  bank  from  the  charging  sys- 
tern  or  from  the  power  distribution  bus.  This  implies  at  least  four  actuation  channels  to 
drive  relays.  .Monitoring  the  power  system  will  require  ■  emetry  inputs.  These 

will  probably  include; 

•  voltage  on  each  battery  bank 

•  charging  current 

•  power  supply  current  draw 

•  regulated  bus  voltage 

Actual  monitoring  and  control  will  be  determined  when  the  pow'er  system  design  is  fi¬ 
nalized. 

F.  MEMORY 

The  memory'  system  can  be  divided  into  three  components.  These  are  the  fixed 
storage  (PROM)  that  holds  the  operating  system  kernel,  vital  RAM  that  holds  system 
vital  data,  and  non-vital  RAM  that  holds  messages  and  telemetry  data. 

1.  PROM  storage  for  operating  system  kernel 

Initial  program  load  will  be  accomplished  from  the  on-board  read  only  memory. 
This  is  one  of  the  vital  links  in  the  system.  If  the  program  in  this  PROM  becomes  cor¬ 
rupted,  it  may  not  be  possible  to  successfully  restart  or  reload  the  satellite  system.  A  high 
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reliability,  fuse  programmed  PROM  will  be  required  to  ensure  that  this  program  docs 
not  become  corrupted.  An  additional  measure  of  reliability  can  be  added  by  using  two 
separate  PROMs  as  was  done  on  L'oSAT-2.  L'oSAT-2  had  a  separate  command  channel 
to  enable  the  alternate  PROM.  As  previously  determined,  PAXS.4T  will  only  have  one 
communication  link.  The  switch  betw'een  PROMs  cannot  be  commanded  directly.  One 
solution  would  be  to  have  the  PROMs  toggle  on  each  reset.  If  one  fails,  then  two  se¬ 
quential  resets  would  be  required  to  restart  on  the  good  PROM.  This  would  be  incon¬ 
venient,  but  better  than  having  a  totally  failed  system. 

Two  alternatives  exist  for  the  size  of  the  program  loaded  into  the  PROM.  The 
preferred  alternative  is  to  have  the  entire  satellite  operating  system  in  the  PROM.  In  this 
case,  a  reset  would  completely  initialize  the  satellite  and  set  it  up  for  store  and  forward 
communications.  If  sufficient  PROM  storage  is  not  available,  or  the  store  and  forward 
software  is  too  complex,  the  PROM  program  could  just  initialize  the  satellite  commu¬ 
nications  link  to  receive  an  uploaded  program.  Typical  satellite  PROMs  vary  between 
two  and  eight  kilobytes  of  storage.  The  LoSAT-2  used  only  512  bytes  of  PROM.  This 
loaded  a  minimal  program  that  enabled  the  processor  to  receive  the  operating  program 
over  the  digital  communication  link  (Ref.  3j.  The  FO-12  was  unique  in  that  it  contained 
no  read  only  memory. 

Since  the  PRO.M  will  contain  the  bootstrap  program  for  the  processor  system, 
software  reliability  is  a  large  concern.  The  software  burned  into  the  PROM  must  remain 
error  free.  PAXSAT  will  have  the  capability  to  be  reprogrammed,  but  this  is  only  pos¬ 
sible  if  the  communication  link  is  properly  initialized  on  the  satellite. 

2.  V'ital  RAM  for  operating  system  functions. 

The  read- write  random  access  memory  (RAM)  can  be  divided  into  two  sections: 

•  vital  R.AM,  in  which  a  bit  error  would  adversely  affect  system  operation,  possibly 
requiring  resetting  the  system 

•  non- vital  RA.M,  in  which  a  bit  error  may  corrupt  a  message  but  does  not  affect 
system  operation. 

A  preferred  system  design  w'ould  have  all  RAM  implemented  in  radiation  hardened  de¬ 
vices  and  would  provide  error  detection  and  correction.  As  previously  mentioned,  radi¬ 
ation  hardened  memory  devices  are  much  more  expensive.  Error  detection  and 
correction  requires  four  additional  bits  per  w'ord  for  eight  bit  words,  and  five  additional 
bits  for  16  bit  words.  Additional  hardware  is  required  for  error  correction  beyond  the 
increase  in  storage  required.  While  error  detection  and  correction  is  a  desired  feature,  it 
is  not  required  for  the  relatively  simple,  low'  cost  design  of  PAXSAT.  Instead,  vital 
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memory  will  rely  on  the  immunity  of  radiation  hardened  to  single  event  upsets. 

Eight  kilobytes  of  storage  will  initially  be  allocated  as  vital  RAM. 

3.  Non-vital  RAM 

Non- vital  RAM  will  compose  the  bulk  of  processor  memor\'.  This  area  will  in¬ 
clude  the  store  and  forward  messages  and  telemetry'  data.  The  size  of  this  RA.M  is  limited 
by  available  power,  volume,  and  addressing  capability.  Within  these  bounds,  this  mem¬ 
ory  should  be  as  large  as  possible.  As  an  alternative  to  radiation  hardening,  this  R-A.M 
should  be  sectioned,  allowing  the  processor  to  disconnect  a  faulted  section  of  memoiy 
from  the  power  supply.  This  will  allow  latch-up  conditions  to  be  reset  or  permanent 
failures  to  be  isolated  to  reduce  impact  on  the  total  system.  For  maximum  reliability, 
the  processor  initialization  sequence  could  remove  power  from  non-vital  memory,  then 
power  up  sections  and  assign  addresses  as  needed.  This  would  prevent  a  non-vital  RA.M 
failure  from  preventing  a  successful  initialization. 

4.  Monitoring 

If  sufficient  telemetry  channels  are  available,  the  current  to  independent  non- 
vital  memory  sections  could  be  monitored.  This  would  provide  data  on  how  current  draw 
changes  in  memory  devices  with  long  term  radiation  exposure.  In  addition,  it  may  pro¬ 
vide  data  to  analyze  failure  of  a  memory  section. 

G.  WATCHDOG  TIMER 

A  method  was  previously  developed  to  reset  the  processor  and  exhibit  control  over 
the  transmitter  if  the  processor  of  HDLC  protocol  controller  failed.  However,  if  the  re¬ 
ceiver  is  the  failed  component,  this  method  will  not  secure  a  malfunctioning  transmitter. 
As  an  additional  safeguard,  a  count  down  timer  could  be  used  to  monitor  processor 
operation.  During  proper  operation,  the  processor  would  reset  the  timer  count  at  regular 
intervals.  If  the  processor  exhibited  a  software  failure,  potentially  placing  the  processor 
in  an  infinite  loop  and  leaving  the  transmitter  keyed,  this  timer  would  expire.  Expiration 
of  this  timer  would  cause  a  software  reset  of  the  processor,  reinitializing  the  system  and 
securing  the  transmitter.  The  periodic  timer  count  reset  must  not  be  an  interrupt  func¬ 
tion.  but  a  normal  function  of  properly  operating  software.  If  it  is  an  interrupt  function, 
it  will  not  break  the  infinite  loop  condition;  the  interrupt  will  return  to  the  infinite  loop 
after  resetting  the  watchdog  count. 

H.  INTERRUPT  CAPABILITIES 

Data  transfer  between  the  processor  and  HDLC  formatter  was  previously  deter¬ 
mined  to  be  optimally  performed  by  processor  interrupts.  The  analog  to  digital  converter 
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may  also  be  designed  to  interrupt  the  processor  when  conversion  results  are  available. 
An  on-board  experiment  may  be  designed  to  interrupt  the  processor  when  service  is  re¬ 
quired.  A  timer  may  be  used  to  interrupt  the  processor  when  the  next  regular  house¬ 
keeping  task  must  be  performed  or  telemetry  data  gathered.  These  imply  that  the 
processor  must  have  at  least  five  levels  of  interrupt  with  appropriate  circuitry  to  receive 
and  process  interrupts.  Typical  interrupt  controllers  provide  eight  channels,  providing 
for  fle.xibility  in  interrupt  design. 

I.  INITIAL  DESIGN  CONCEPT 

The  concepts  explored  in  the  above  sections  determine  the  desired  baseline  design 
of  the  PANSAT  on-board  processor.  These  functions  and  interfaces  are  illustrated  in 
Figure  7  on  page  29. 
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Figure  7.  PANSAT  processor  initial  system  concept 
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III.  PROCESSOR  DESIGN 


A.  PROCESSOR  SELECTION 

Current  Space  Systems  Acadeinic  Group  projects  use  the  NSC-800  as  the  basis  for 
processor  systems.  The  current  design  has  at  least  four  years  of  operation  and  testing. 
However,  a  more  powerful  system  is  required  to  implement  the  store  and  forward  mes¬ 
sage  system.  A  previous  design  was  attempted  with  an  8085.  This  processor  did  not  have 
high  enough  throughput  for  even  the  simpler  requirements  of  previous  experiments. 

The  microcontrollers  {\1C6SHC11  and  8096)  offer  interesting  possibilities  for  space 
based  control  applications.  They  contain  a  processor,  RA.M.  ROM,  clock,  reset  circuit, 
watchdog  timer,  interrupt  circuit,  programmable  timer,  serial  port,  several  parallel  ports, 
and  an  .A  D  converter,  all  within  a  single  chip.  1  he  disadvantage  of  using  a  microcon¬ 
troller  is  that  on  chip  memor>'  is  limited  and  addressing  memory  off  chip  is  clumsy.  Ad¬ 
ditionally,  read  only  memory  is  implemented  in  EPROM  which  is  not  suitable  for  higher 
radiation  environments  experienced  in  space.  Procuring  a  chip  with  ROM  instead  of 
EPROM  requires  mask  charges  and  large  orders;  otherwise  unit  costs  are  high.  This 
eliminates  the  microcontrollers  from  consideration. 

The  8086  and  MC68000  are  both  sophisticated,  medium  performance  micro¬ 
processors.  The  advantages  of  the  MC6S000  are: 

•  the  data  bus  and  address  lines  are  not  multiplexed  (as  in  the  8086) 

•  memoiy  and  I  O  interface  is  simplified  through  use  of  DTACK  protocol, 

•  the  address  bus  uses  24  bits  (versus  20  in  the  8086),  and 

•  peripherals  are  mapped  into  memory,  simplifying  1  O  data  transfer. 

The  advantages  of  the  8086  are: 

•  a  full  family  of  CMOS  products  exists,  including  commercial,  industrial,  high  reli¬ 
ability.  and  radiation  hardened.  This  allows  initial  design  in  low  cost  components 
with  the  more  expensive  components  used  in  the  final  implementation. 

•  A  large  number  of  software  development  tools  are  available. 

•  Software  presently  exists  that  implements  the  store  and  forward  protocol. 

•  Other  satellites  have  been  constructed  based  on  the  8086,  thereby  establishing  a 
history  of  reliable  space  operation. 

Based  on  the  8086  advantages,  an  8086  system  will  be  designed.  The  specific  processor 
targeted  is  the  Harris  80C86RH,  a  radiation  hardened,  C.MOS  version  of  the  8086. 


B.  PROCESSOR  MODE  SELECTION 

The  S0CS6RH  can  operate  in  eittier  minimum  or  maximum  mode.  In  maximum 
mode  bus  control  signals  are  multiplexed  on  three  pins:  SO*,  SI*,  and  S2*.  (The  *  is 
used  to  indicate  an  active  low  signal.)  These  signals  are  used  by  the  82C88  bus  controller 
to  synchronize  bus  operations  and  to  allow  for  more  than  one  bus  master.  Since  the 
maximum  mode  requires  an  additional  chip  and  since  the  flexibility  of  having  more  than 
one  processor  access  the  bus  is  not  required,  the  minimum  mode  will  be  used.  Minimum 
mode  is  selected  by  tying  MN  MX*  to  Vdd. 

In  minimum  mode,  the  80C86RH  directly  generates  signals  necessaiy  to  control  read 
or  write  to  memor>'  or  peripheral  devices.  These  signals  are  RD*,  \VR*,  and  M  lO*. 
RD*  is  active  for  reading  from  devices.  WR*  is  active  when  writing  to  devices.  M  lO* 
is  high  when  accessing  memory  address  space  and  low  when  accessing  lO  (or  peripheral) 
address  space.  The  80C86RH  data  bus  is  16  bits  wide,  but  it  can  access  individual  byte 
items.  The  processor  uses  AO  and  BME*  to  indicate  whether  an  action  aflects  a  byte  or 
a  whole  word.  The  effect  of  these  signals  is  shown  in  Table  6  [Ref  1 1:  p.  B-8].  When  a 
byte  operation  is  performed,  the  bus  interface  unit  inside  the  80C86RH  automatically 
routes  the  byte  from  the  high  or  low  half  of  the  data  bus  to  the  proper  internal  register. 


Table  6.  BYTE  SELECTION  CONTROL 


mull 

AO 

Bytes  accessed 

0 

0 

Whole  word 

0 

1 

Upper  byte  to  from  odd  address 

1 

0 

Lower  byte  to  from  even  address 

1 

1 

None 

In  either  mode  of  operation,  address  and  data  information  are  time  multiplexed  onto 
the  same  bus.  The  80C86RH  bus  cycle  consists  of  four  clock  periods.  These  are  labeled 
T1  through  T4.  (In  some  cases,  wait  states  are  inserted  between  T3  and  T4.  These  are 
indicated  by  Tw.)  During  Tl,  the  processor  provides  the  selected  address  on  A0-A19. 
During  the  remaining  periods,  the  processor  will  read  data  from  or  write  data  to  A0-A15 
while  A16-A19  provide  status  and  control  for  maximum  mode  system.  Address  and  data 
information  must  be  demultiplexed  from  A0-A19  external  to  the  80C86RH.  In  mini¬ 
mum  mode,  the  processor  generates  ALE,  DEN*,  and  DT/R*  to  control  demultiplexing. 
Two  methods  of  demultiplexing  are  available.  The  first  method  uses  synchronous 
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memor)'  devices  designed  to  operate  directly  with  the  80C86RH.  These  memory  devices 
have  internal  latches  to  hold  the  address  during  decoding  and  memory  access.  One  such 
device  is  the  Harris  92560  64  kilobyte  by  8  bit  synchronous  R.'XM  module.  Using 
synchronous  modules  presents  several  limitations.  A  limited  selection  of  devices  is 
available.  These  devices  are  not  pin  compatible  with  standard  28  pin  memory  devices. 
Inability  to  acquire  the  exact  device  that  the  system  is  designed  to  use  may  force  a  re¬ 
design.  These  synchronous  RAM  modules  are  not  typically  available  in  radiation  hard¬ 
ened  or  high  reliability  versions.  In  addition,  unless  synchronous  decoders  are  used,  the 
upper  address  bits,  AO,  and  BHE’*'  must  still  be  latched  externally  for  chip  select  decod¬ 
ing.  Most  80C86RH  peripheral  devices  are  not  synchronous  so  address  bits  used  by  pe¬ 
ripherals  must  also  be  latched.  Last,  the  drive  capability  of  the  80C86RH  outputs  is 
limited,  so  an  external  bus  driver  may  still  be  required.  With  these  disadvantages,  a 
synchronous  system  using  the  multiplexed  bus  is  not  the  solution  for  PANSAT. 

The  second  demultiplexing  method  uses  external  latches.  These  latches  are  loaded 
with  an  address  during  Tl.  They  then  maintain  a  stable  address  throughout  the  entire 
bus  cycle.  Since  PANSAT  will  be  a  multiple  board  system,  two  additional  options  exist. 
These  are  demultiplexing  the  buses  on  the  main  board  and  distributing  demultiplexed 
data,  or  distributing  the  multiplexed  bus  and  providing  address  latches  on  each  board  for 
local  demultiplexing.  Since  the  circuit  boards  will  be  separated  by  several  inches  at  most, 
and  the  PANSAT  design  is  to  be  simple,  only  one  set  of  address  latches  will  be  used  and 
the  demultiplexed  bus  distributed  to  the  secondary  boards. 

The  80C86RH  is  rated  to  operate  from  DC  up  to  five  MHz.  (Since  the  circuit  is 
CMOS  and  does  not  use  dynamic  storage,  the  clock  can  be  stopped  without  loss  of  sta¬ 
tus.  This  is  different  from  the  initial  8086  which  used  dynamic  storage  and  had  a  mini¬ 
mum  clock  frequency  of  two  MHz.)  At  maximum  rated  frequency  the  processor  requires 
a  33  percent  duty  cycle  clock.  The  clock  must  be  active  (high)  for  33  percent  of  the  clock 
period;  this  is  to  ensure  that  the  clock  inactive  time  is  at  least  118.6  nanoseconds.  If  a 
frequency  less  than  4.2  MHz  is  selected,  a  symmetric  clock  may  be  used.  In  this  design, 
a  five  MHz  clock  will  be  assumed.  This  gives  a  clock  period  of  200  nanoseconds  and  a 
bus  cycle  time  (with  no  wait  states)  of  800  nanoseconds.  This  timing  is  conservative  by 
current  device  standards  and  will  allow  wide  flexibility  in  choosing  memory  and  periph¬ 
eral  devices. 
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C.  BUS  DEMULTIPLEXING 

A  typical  minimum  system,  shown  in  Figure  8  on  page  34,  uses  three  82C82  octal 
latching  bus  drivers  to  demultiplex  the  address  bus  and  two  82C08RH  bus  transceivers 
to  drive  the  data  bus.  These  circuits  are  not  appropriate  for  PANSAT.  The  82C82  is 
not  available  in  a  radiation  hardened  version.  This  is  sohed  by  substituting  three 
54HC573  octal  latches  in  place  of  the  82C82s.  The  54HC573s  are  functionally  identical 
to  the  82C82s  and  are  available  in  high  reliability  versions.  The  timing  of  the  82C08  is 
marginal  for  the  system.  System  timing  using  the  82C08  in  a  synchronous  design  with 
92560  synchronous  RAM  modules  is  showm  in  Figure  9  on  page  35.  The  worst  case 
timing  is  shown.  DEN*  goes  active  110  nanoseconds  after  the  rising  edge  of  T2.  This 
activates  the  82C08  output  which  has  a  130  nanosecond  delay  until  the  output  is  valid. 
As  shown,  this  will  present  data  to  the  80C86RH  exactly  at  the  setup  time  with  no 
margin.  To  use  the  82C08  reliably,  the  system  must  be  slowed.  As  an  alternative  to 
slowing  the  system,  the  82C08s  can  be  replaced  by  54HC245  transceivers.  These  are 
functionally  identical  to  the  82COSs  but  have  only  a  30  nanosecond  delay  from  enable 
to  output. 

The  data  bus  transceivers  are  not  required  for  system  bus  demultiplexing  as  this  was 
accomplished  by  the  address  latches.  They  serve  two  other  purposes.  First,  they  increase 
the  output  drive  of  the  80CS6RH  and  provide  isolation  of  data  bus  components  from 
the  processor.  Second,  they  reduce  bus  contention  by  isolating  the  data  bus  from  the 
address  bus  during  T1  while  the  processor  is  outputting  an  address. 

Three  54HC573s  are  required  to  latch  a  20  bit  address  plus  BHE*.  Latching  the 
address  is  controlled  by  ALE.  The  latch  outputs  are  permanently  enabled  by  tying  out¬ 
put  enable  (OE*)  to  ground.  The  80C86RH  does  not  provide  a  signal  that  could  be  di¬ 
rectly  used  to  enable  address  latch  output  only  when  a  valid  address  exists.  Therefore, 
the  address  latch  output  will  be  permanently  enabled.  Permanently  enabling  these  out¬ 
puts  will  not  cause  contention  on  the  demultiplexed  address  bus  as  the  80C86RH  is  the 
only  source  of  an  address. 

Two  54HC245s  are  required  to  drive  a  16  bit  data  bus.  Direction  of  transfer  is  con¬ 
trolled  by  DT;  R*.  The  output  enable  (OE*)  of  the  54HC245s  is  controlled  by  DEN* 
from  the  80C86RH.  This  signal  is  active  only  during  T2,  T3,  and  T4,  after  the  address 
output  has  been  latched  and  the  multiplexed  system  bus  is  ready  for  data  transfer.  Op¬ 
eration  of  DT  R*.  DEN*,  and  54HC245  direction  of  transfer  is  shown  in  Table  7  on 
page  34. 
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Figure  8.  Minimum  mode  HS-80C86RH  typical  configuration:  [Ref.  6,  p.  4-65] 


Table  7.  DT/R*  AND  DEN*  CONTROL  OF  54HC245 


DEN* 

(EN*) 

DT/R* 

(A-B) 

data  direction 

54I1C245  function 

0 

0 

read  data  (to  processor) 

B  to  A 

0 

1 

write  data  (from  processor) 

A  to  B 

1 

X 

none 

high  impedance 

The  interconnection  of  the  80C86RH,  54HC245s,  and  54HC573s  are  shown  in  Fig¬ 
ure  10  on  page  36.  (The  symbol  for  pin  1  of  the  54HC245  may  be  confusing  as  it  indi¬ 
cates  -»  5  is  an  active  low  signal.  In  fact,  this  signal  behaves  as  shown  in  Table  7  on 
page  34.)  In  this  and  all  following  circuit  schematics  the  following  signal  names  are 
used: 

•  ADO  through  AD  19  for  the  multiplexed  system  bus, 

•  BDO  through  BD15  for  the  demultiplexed  (bulfered)  data  bus,  and 

•  BAO  through  BA  19  and  BBHE*  for  the  demultiplexed  (buffered)  address  bus. 
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Figure  10.  Paiisat  processor  main  board 
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D.  OTHER  PROCESSOR  CONNECTIONS 


The  80C86RH  TEST*  pin  operates  with  the  80C86RH  WAIT  instruction.  A  WAIT 
instruction  will  cause  the  processor  to  idle  while  testing  the  TEST*  input.  When  the 
TEST*  input  goes  active,  processor  activity  will  resunte.  This  pin  could  be  connected  to 
a  timer  output  to  allow  the  processor  to  run  idle  cycles  for  a  predetermined  time.  How¬ 
ever,  this  method  of  synchronization  could  lead  to  an  infinite  loop  if  the  timer  was  im¬ 
properly  initialized.  S3nchroni2ation  with  external  devices  such  as  telemetiy  collection 
or  an  embarked  experiment  is  better  accomplished  through  an  interrupt  structure.  The 
TEST*  input  is  connected  to  ground  (permanently  active)  so  a  WAIT  instruction  will 
have  no  effect. 

The  HOLD  input  allows  another  processor  to  access  the  local  bus.  When  HOLD  is 
active,  the  80C86RH  will  place  the  system  bus  and  control  lines  in  a  high  impedance 
state  until  HOLD  goes  inactive.  This  feature  is  not  desired  and  HOLD  is  made  perma¬ 
nently  inactive  by  tying  to  ground.  HLDA  is  an  output  acknowledging  HOLD  and  has 
no  connection.  (Figure  10  on  page  36  shows  HOLD  as  RQ*  GTO*  and  HLDA  as 
RQ*,'GT1*.  These  are  the  maximum  mode  pin  definitions.) 

E.  CLOCK  GENERATION 

To  operate  the  80C86RH  at  the  maximum  rated  speed  of  five  MHz  requires  an 
assymetric,  33  percent  duty  cycle  clock.  This  can  be  generated  by  the  82C85RH  clock 
generator  circuit.  The  82C85RH  requires  a  frequency  source  operating  at  three  times  the 
desired  clock  frequency.  This  can  be  generated  by  placing  a  15  .MHz  parallel  resonant, 
fundamental  mode  ciystal  across  X!  and  X2  and  tying  F,C*  low  (to  select  internal  fre¬ 
quency  source).  To  ensure  stable  oscillator  operation,  two  capacitors  are  added  such  that 
their  combined  capacitance  (  ^  ^^tches  the  load  capacitance  required  for  the 

crystal  [Ref  6;  p.  4-143].  The  values  for  these  capacitors  will  be  determined  when  the 
actual  crystal  is  obtained.  The  required  33  percent  duty  cycle  clock  is  available  on  CLK 
and  may  be  connected  directly  to  the  80C86RH  CLK  input. 

In  addition  to  clock  generation,  the  82C85RH  also  provides: 

•  power  on  reset  generation  using  a  Schmidt  trigger, 

•  clock  start  stop  and  slow, 'fast  control, 

•  two  separate  ready  and  ready  qualification  inputs, 

•  a  50  percent  duty  cycle  clock,  and 

•  a  peripheral  clock  operating  at  one  sixth  the  crystal  frequency. 


The  start  stop  control  requires  an  82CS8  bus  controller  or  discrete  circuitry  to  decode 
the  halt  command  on  SO",  SI*,  and  S2*.  In  addition,  once  the  clock  is  stopped  an  ex¬ 
ternal  event  (interrupt)  is  required  to  restart  the  clock.  '1  o  prevent  a  HALT  corrmiand 
from  stopping  the  clock  without  external  means  to  restart  the  clock,  this  start  stop  ca¬ 
pability  will  not  be  used  in  this  design.  The  start  command  will  be  permanently  enabled 
by  tying  START  to  Vdd. 

The  Schmidt  trigger  reset  circuit  generates  the  required  width  reset  pulse  for  the 
system.  The  minimum  high  voltage  on  the  reset  input  is  2.8  volts.  An  external  resistor- 
capacitor  (RC)  network  must  be  added  to  keep  the  82C85RH  reset  input  below  2.8  volts 
until  the  power  supply  stabilizes  at  five  volts,  then  allow  this  input  to  increase.  The 
capacitor  voltage  is  given  by: 

Vc(t)=v(\-e~~Rc')  (4) 

where  V  is  the  power  supply  voltage  and  t  is  time.  The  value  of  RC  depends  on  power 
supply  characteristics  and  will  be  determined  when  power  supply  design  is  complete.  A 
communications  system  reset  output  will  also  be  connected  to  the  82C85RH  reset  input. 
Due  to  the  external  pullup  resistor,  this  second  input  should  be  connected  through  an 
open  collector  output  stage. 

Ready  generation  will  be  examined  with  peripheral  and  memory  design.  The  re¬ 
maining  82C88RH  functions  will  not  be  used.  The  80C85RH  connections  are  shown  in 
Figure  10  on  page  36. 

F.  80C86RH  PERIPHERALS 

Peripheral  devices  supporting  the  80C86RH  may  be  addressed  by  one  of  two  meth¬ 
ods.  They  can  be  mapped  into  the  2“  address  memory  space  or  into  a  separate  2‘®  ad¬ 
dress  1,  0  space.  The  advantage  of  mapping  into  the  memory  space  is  that  all  memory 
operations,  such  as  MOV,  PUSH,  and  POP,  may  be  directly  applied  to  peripheral  de¬ 
vices.  However,  the  80C86RH  cannot  directly  move  from  one  memory  location  to  an¬ 
other.  This  requires  two  separate  bus  operations  and  two  separate  instructions.  If 
mapped  to  the  I/O  space,  all  transfers  must  go  through  register  AX  or  AL  using  the  IN 
or  OUT  instructions.  Since  both  methods  require  two  instructions  and  two  bus  cycles 
to  transfer  a  byte  from  memory,  the  only  advantage  to  mapping  peripherals  into  the 
memory  address  space  is  the  ability  to  use  any  register  to  temporarily  hold  the  trans¬ 
ferred  byte.  If  memory  mapping  is  used,  some  portion  of  address  space  is  lost.  In  certain 


38 


instances,  the  IN  and  OUT  instructions  are  faster  than  memory  instructions.  For  these 
reasons,  PANSAT  processor  peripherals  will  be  mapped  to  the  I  O  space.  Chip  select 
lor  peripneral  devices  will  be  considered  after  addressing  requirements  for  all  peripheral 
devices  are  examined. 

The  peripherals  required  for  the  system  depend  on  the  functions  desired.  PANSAT 
will  require  the  following  peripherals: 

•  Analog  to  digital  converter, 

•  parallel  input  output  ports  for  device  control, 

•  interrupt  controller  (since  the  80C86RH  will  only  recogni7e  two  levels  of  interrupt 
without  external  circuitry), 

•  a  timer  circuit(s)  for  the  w'atchdog  timer,  and 

•  an  HDLC  protocol  controller. 

The  selection  and  connection  of  these  items  is  described  below. 

1.  Analog  to  digital  converter 

The  analog  to  digital  converter  will  receive  analog  signals  through  a  series  of 
multiplexers  and  provide  a  digital  output  to  the  processor.  Typically  eight  bit  accuracy 
would  suffice  for  PANSAT  purposes.  However,  the  ideal  choice  for  the  PANSAT  is  the 
Intersil  ICL7115.  This  is  available  in  CMOS  and  provides  14  bits  of  accuracy.  In  addi¬ 
tion,  interface  to  the  80C86RH  is  simplified  as  it  will  directly  map  to  the  TO  space  and 
recognize  processor  signals  for  control.  WR*  will  initiate  a  conversion  cycle  and  RD'*' 
will  allow  the  processor  to  read  the  results. 

The  ICL71I5  will  perform  14  bit  conversions  in  40  microseconds  using  a  500 
kHz  clock.  Rather  than  add  a  500  kHz  crystal  to  the  circuit  (crystal  connections  are 
available  on  the  1CL7115),  the  system  clock  is  divided  below'  500  kHz  to  provide  the 
conversion  clock.  Proper  system  operation  will  then  rely  on  only  one  clock  rather  than 
two  clocks.  The  82C85  50  percent  duty  cycle  clock  (operating  at  five  .MHz)  is  used  to 
clock  a  54HC161  binary  counter.  The  QD  output  then  provides  a  clock  that  is  1  16th 
the  input  frequency,  or  312.5  kHz.  This  provides  a  conversion  time  of  64  microseconds. 
(The  54HC161  connections  to  implement  a  divide  by  16  counter  are  showm  in 
Figure  10  on  page  36.)  This  312.5  kHz  clock  is  connected  to  the  OSC2  input  of  the 
ICL7115. 

The  ICL7115  provides  14  bits  of  output  plus  an  over-range  flag.  The  output  bits 
are  connected  to  BD0-BD13  w’hile  the  over-range  flag  is  connected  to  BD14.  This  allows 
a  single  word  transfer  (such  as:  IN'  address,AL)  to  read  conversion  results.  On  occasion. 
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the  programmer  may  wish  to  load  only  the  low  or  high  byte  of  the  conversion.  This  is 
controlled  by  the  AO  and  BUS  pins  of  the  ICL7I15.  These  are  connected  to  BAl  and 
BA2  to  perform  this  selection.  BAO  cannot  be  used  for  this  selection  as  it  indicates 
whether  the  low  or  high  byte  of  the  data  bus  is  to  be  read  by  the  80C86RH  processor. 
In  the  ICL7115,  selection  of  low  or  high  byte  routes  the  selected  byte  to  the  low  byte 
of  the  data  bus.  Therefore  AO  must  be  low  (0)  to  read  the  low  byte  of  the  data  bus. 
Table  8  summarizes  the  control  of  the  ICL7115. 


Tables.  ICL71 15  CONTROL 


WR- 

RD* 

BUS 

(BA2) 

AO 

(BAl) 

Action 

0 

X 

X 

X 

Initiate  conversion 

X 

0 

0 

0 

low  byte  to  BD0-BD7  (A0  =  0) 

X 

0 

0 

1 

high  byte  to  BD0-BD7  (A0  =  0) 

X 

0 

1 

X 

both  bytes  to  BD0-BD14  (AO.BHE*  =  0) 

X 

1  1 

X 

X 

high  impedance  output 

'■'he  analog  signal  is  input  on  Vinf.  Vins  provides  an  output  of  the  voltage 
sensed  by  the  ICL71 15.  This  can  be  used  to  drive  an  op  amp  to  restore  any  voltage  drop 
in  sensing  lines.  Similar  arrangements  are  possible  on  the  reference  voltage  and  analog 
ground  inputs.  Due  to  the  small  size  of  PANSAT,  these  op  amps  will  probably  not  be 
necessar}’  and  are  shown  as  optional  in  Figure  1 1  on  page  42.  When  the  telemetry  sys¬ 
tem  design  is  finalized,  the  telemetry  designer  will  determine  the  need  for  these  op  amps. 
The  VREF  input  should  go  to  the  best  regulated  high  voltage  on-board  PANSAT  to 
provide  a  stable  reference.  (All  conversions  are  referenced  as  a  percentage  of  this  volt¬ 
age.) 

The  analog  voltage  input  to  the  ICL7115  is  selected  by  two  levels  of  54HC4051 
analog  multiplexers  providing  36  telemetry  input  channels.  Up  to  four  additional 
54HC4051S  may  be  added  to  increase  input  to  64  channels  while  maintaining  only  two 
level  multiplexing.  The  primary  54HC4051  is  controlled  by  four  bits  of  a  parallel  output 
port,  with  one  bit  enabling  output  and  three  bits  selecting  the  input  channel.  The  second 
level  multiplexers  are  similarly  controlled  as  a  group  by  the  remaining  four  bits  of  the 
parallel  port. 
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The  1CL71 15  indicates  conversion  is  complete  by  a  high  level  on  EOC.  This  can 
be  used  to  cause  an  interrupt  request  for  the  80CS6RM  to  read  the  conversion  value  and 
initiate  the  next  conversion.  The  ICL7115  and  54HC4051  connections  are  shown  in 
Figure  11  on  page  42.  Specifications  for  the  ICL7115  are  found  in  reference  12. 

2.  Parallel  input/output  port 

The  PANSAT  processor  requires  a  parallel  output  capability  to  control  the 
telemetry^  multiplexers  and  other  device  on,  off  control.  The  82C55RH  provides  three 
bidirectional  eight  bit  ports  that  can  be  used  for  this  purpose.  Since  the  80C55RH  is  an 
eight  bit  device,  it  is  connected  to  only  the  lower  eight  bits  of  the  data  bus  (BD0-BD7). 
The  80C55RH  has  four  internal  registers,  selected  by  AO  and  Al.  However,  the 
80C55RH  AO  cannot  be  connected  to  BAO.  BAO  selects  the  low  byte  for  a  transfer,  and 
if  BAO  equaled  1  to  control  80C55RH  register  selection,  this  would  disable  transfer  from 
the  low  eight  hits  of  the  data  bus.  Therefore  AO  is  connected  to  BAl  and  Al  to  BA2. 
The  operation  of  these  signals  is  summarized  in  Table  9. 

Table  9.  80C55RH  REGISTER  SELECTION 


RD’'"'  is  connected  to  the  system  read  signal  and  WR*  is  connected  to  the  system 
write  signal.  These  signals  determine  whether  a  control  or  output  word  is  to  be  written 
to  or  read  from  the  82C55RH.  The  82C55RH  RESET  input  is  connected  to  the  system 
reset  signal  generated  by  the  82C85RH.  The  chip  select  input  will  be  considered  later. 

The  82C55RH  has  three  operating  modes  with  multiple  submodes.  In  the 
PANSAT  processor,  only  simple  output  is  required.  This  is  mode  zero.  All  three  ports 
are  configured  for  output  by  writing  10000000b  (128h)  to  the  control  word.  Port  A  is 
connected  to  the  multiplexing  system  for  the  1CL7115.  The  control  effect  of  these  con¬ 
nections  is  summarized  in  Figure  12  on  page  43. 

The  parallel  port  also  implements  device  control  through  port  C.  Port  C  was 
selected  for  this  control  since  individual  bits  of  port  C  can  be  set  or  reset  with  a  special 
control  word.  This  allows  changing  status  of  one  device  without  causing  a  glitch  in  the 


14  BIT  A/D  CONVERTER 

. AAxea 

ICL7115 


SIGNAL  LEVEL  RESTORER 
(OPTIONAL) 


•  STABLE  REFERENCE  VOLTAGE 


ANALOG  GROUND 


CS»A/D-^  CS 
RO»*:(!f  RO 
UR*-^  WR 
eAl-|-  AO 
602^  BUS 

iNTA/0—  eoc 


COMP  ■il-GND 
PROG  If+SV 
TEST^+5V 
017  I^NC 
B16  ^NC 


DGND  — GND 
32 

SC  :5^+SV 
OSCi  -IfNC 
0SC2  — CLK.3 


ANALOG  MUX 
. AAR02 
54HC4051 


TLM15-“  Y7 
TLM14-|-  Y6 
TLM13-^ Y5 
TLMia-^  Y4 
TLMU*^  Y3 
TLM10-|^  Y2 
TLMSI^YI 
TLMS-^YO 
PA27I-A2 
PAl-^Ai 
PAO— AO 


ANALOG  MUX 
. AAS02 
54HC4051 


TLM7-^Y7 
TLM6-|-Y6 
TLM5-— Y5 
TLM4>~  Y4 
TLM3A|- Y3 
TLM2-^  Y2 


ANALOG  MUX 

.AAU02 

54HC4051 


TLMSl-^  Y7 
TLM30“|-YB 
TLM29-^  YS 
TLM28-^  Y4 
TLM27-JI-  Y3 
TLM26Yf-  Y2 
TLM25-^Yi 
TLM24-^Y0 
PA27I-A2 
PAl^^Al 
PAO—  AO 


.AAT02 

54HC405J 


TLM23-^'t7 
TLM22-|- YB 
TLM21-^  YS 
TLM20-^ Y4 
TLMlsjl-  Y3 
TLMIS^  Y2 
TLMlT-j^  Y1 
TLMIB-^  YO 
PA2^A2 
PAl A1 
PAO—  AO 


ANALOG  MUX 

.AAV02 

54HC40S1 


TLNSS-J- Y7 
TLM34-|- Y6 
TLM33-f-  Y5 
TLM32-^Y4 
- ^Y3 
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PAS-f-MZ 
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PRIMARY 

MULTIPLEXER 

ENABLE 

secondary 

multiplexers* 

ENABLE 

PRIMARY 

rLcTircEXER 

CHANNEL 

BIT  7 

BIT  6 

BIT  S 

BIT  4 

BIT  3 

BIT  2 

BIT  1 

BIT  e 

THIS  CONTROL  WORD  IS  URITTEN  TO  PORT  A  TO  CONTROL  ICL7115  MULTIPLEXER  INPUTS. 


Figure  12.  ICL71 15  input  channel  selection 

status  of  another  device.  This  control  word  is  shown  in  Figure  13  on  page  44.  Two 
54HC4016  quad  bilateral  switches  are  used  to  provide  eight  channels  of  digital  control. 

When  the  82C55RH  is  reset,  all  ports  are  set  to  input  mode  with  input  pins 
pulled  up  to  Vdd.  To  have  this  condition  disable  all  devices  controlled  through  the 
5411C4016S,  the  port  C  outputs  are  connected  to  the  5411C4016s  through  inverters. 
Since  the  82C55RH  outputs  are  latched  internally,  an  external  latch  is  not  required.  If 
more  than  eight  channels  of  control  are  required,  port  C  could  be  used  to  drive  two 
54nC259  eight  bit  addressable  latches,  each  driving  two  54HC4016s.  Ihis  will  provide 
sixteen  channels  of  control.  As  an  alternative,  port  B  could  also  be  used  to  drive  two 
54HC4016S.  However,  port  B  is  not  bit  addressable  and  may  not  provide  glitch  free 
control.  At  present,  port  B  is  reserved  for  future  use.  Figure  14  on  page  46  shows  the 
82C85ARH  connections. 

3.  HDLC  protocol  controller 

The  need  for  an  HDLC  controller  to  format  the  packet  communications  was 
analyzed  previously.  The  8273  HDLC  controller  can  be  mapped  directly  into  the  1,0 
space  like  other  peripherals.  Like  the  82C55RH,  the  8273  is  an  eight  bit  device.  This 
implies  the  same  limitations  on  using  BAG  as  an  address  input.  Ihe  data  bus 
connections,  RD*,  WR*,  and  RESET  connections  are  similar  to  the  82C55RH.  The 
previous  analysis  showed  that  an  interrupt  driven  HDLC  controller  would  be  sulFicient 
for  the  PANSAT  processor.  The  8273  is  therefore  connected  for  interrupt  driven  control. 
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Figure  13.  Bit  set/reset  control  word  format:  (Ref.  6,  p.  4-120] 

Two  of  the  four  DMA  controls  are  still  used  to  control  register  access.  The  others 
(TxDRQ  and  RxDRQ)  are  unused.  The  8273  AO,  Al,  TxDACK*,  and  RxDACK* 
connections  are  used  with  RD*  and  WR*  to  access  the  nine  internal  registers. 
TxDACK*  selects  the  transmit  data  register;  RxDACK*  selects  the  receive  data  register. 
Since  the  8273  is  designed  to  operate  with  a  DMA  controller,  TxDACK*  and 
RxDACK*  do  not  require  CS*  to  be  active  to  select  these  registers.  Iherefore,  address 
lines  cannot  be  used  to  control  TxDACK*  and  RxDACK*  as  this  may  result  in  errone¬ 
ous  data  transfers.  These  two  signals  will  be  generated  separately  by  the  chip  select  de¬ 
coder  to  prevent  inadvertent  data  transmission  or  bus  contention. 

The  remaining  8273  registers  are  accessed  only  when  CS*  is  active.  These  reg¬ 
isters  may  be  controlled  by  BA2  and  BAl  connected  to  Al  and  AO  respectively.  (As 
previously  discussed,  the  system  BAO  is  not  used  to  control  register  select  in  eight  bit 
peripl\e/als.)  The  result  of  these  configuration  is  that  the  8273  uses  three  peripheral  chip 
selects.  One  is  used  to  control  TxDACK*,  one  is  used  to  control  RxDACK*,  and  one 
for  the  8273  chip  select  (and  remaining  registers).  A  summary  of  these  signals  is  shown 
in  Table  10  on  page  47.  The  connection  of  TxDACK*  and  RxDACK*  will  cause  the 
registers  controlled  by  these  signals  to  be  addressed  as  separate  I/O  devices. 

FLAGDET*  is  connected  to  the  interrupt  controller  to  provide  the  capability 
for  interrupting  the  processor  when  the  8273  detects  a  valid  flag.  The  remaining  con¬ 
nections  go  to  the  communication  package.  The  8273  provides  sophisticated  modem 
interface  and  control  capability.  This  capability  is  detailed  in  Reference  13  (pp.  8-163  to 
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8-187).  The  connections  required  and  8273  operating  mode  desired  will  be  determined 
when  the  communication  package  design  is  finalized. 

The  8273  IlDLC  controller  does  present  one  disadvantage;  it  is  not  available  in 
a  CMOS  version  (as  of  Februar}-,  1989).  The  TTL  version  consumes  one  watt  of  power. 
This  would  be  a  significant  fraction  of  the  processor  power  budget.  There  are  several 
solutions  to  overcome  this  disadvantage: 

•  implement  the  DLC  protocol  in  software  and  replace  the  8273  with  a  US.ART, 

•  implement  the  DLC  protocol  in  discrete  CMOS  hardware  as  done  in  FO-12. 

•  use  one  of  the  54HC4016  channels  to  power  down  the  8273  when  not  in  use,  or 

•  use  a  simpler,  byte  serial  protocol. 

The  disadvantage  of  software  implementation  of  a  bit  serial  protocol  was  discussed  pre¬ 
viously.  Using  a  protocol  other  than  AX. 25  defeats  one  of  the  main  purposes  of 
PANSAT.  This  leaves  only  the  second  and  third  options,  of  which  the  third  is  preferred. 
The  effect  of  powering  down  the  8273  in  an  active  circuit  will  have  to  be  tested  when  the 
breadboard  design  is  completed.  A  discrete  HDLC  implementation  for  PANSAT  is  a 
complex  problem,  possibly  presenting  another  thesis  topic. 

If  the  8273  is  powered  down,  a  method  is  needed  to  signal  the  80C86RH  when 
to  power  up  and  initialize  the  8273.  The  carrier  detect  line  (CD*)  from  the  communi¬ 
cation  package  can  be  used  to  provide  an  interrupt  to  start  this  sequence.  The  8273 
connections  are  shown  in  Figure  14  on  page  46. 

4.  Tinier 

Implementation  of  the  watchdog  timer  function  requires  a  timer  that  will  inter¬ 
rupt  the  processor  and  cause  the  processor  to  reinitialize  if  this  timer  is  not  reset  before 
the  timer  count  ends.  This  function  can  be  accomplished  by  using  a  82C54RH  pro¬ 
grammable  interval  timer.  The  82C54RH  provides  three  timer  channels  that  can  be  used 
for  multiple  purposes.  The  counters  have  multiple  modes  (detailed  in  reference  6,  pp. 
4-100  to  4-115)  but  the  only  mode  needed  is  mode  zero,  interrupt  on  terminal  count.  The 
timer  two  output  is  connected  to  the  non-maskable  interrupt  (NMl)  of  the  82C86RII 
to  provide  the  watchdog  timer  function.  The  remaining  counters  (one  and  zero)  are  used 
to  provide  interrupts  for  other  functions,  such  as  implementing  a  real  time  clock.  Since 
one  possible  operating  mode  is  a  programmable  rate  generator,  one  of  these  timers  could 
be  programmed  to  generate  the  500  kHz  (or  slower)  clock  for  the  ICL7115.  This  intro¬ 
duces  another  possible  failure  mode  for  A  D  conversion:  the  82C54RH  must  be  operat¬ 
ing  and  programmed  properly  for  successful  conversion.  It  is  preferable  to  use  the 
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Figure  14.  HDLC,  parallel  interface,  and  device  control 
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Table  10.  8273  REGISTER  CONTROL 

RxDACK-  A1  TaO  RD'-'  WR- 
(BA2)  (BAD _ 

0 _ 1  0 _ 

0 _ 0  1 _ 

j _ 1  0 _ 

j _ 0  1 _ 

0 _ 1  0 _ 

0 _ 0  1 _ 

j _ 1  0 _ 

j _ 0  1 _ 

2v _ 1  0 _ 

X _ 0  1 _ 

simpler  (hence  more  reliable)  54HC16J  divide  by  16  circuit  to  reduce  the  five  MHz  clock 
below  500  kHz. 

The  82C54RH  timers  are  16  bit  timers  without  prescaling.  (The  clock  frequency 
is  not  divided  before  decrementing  the  count.)  If  the  timers  operated  at  the  full  five  MHz 
system  clock  frequency,  the  maximum  delay  possible  would  be  13.11  milliseconds. 
However,  a  312.5  kHz  clock  is  available  from  the  54HC161.  Using  this  to  drive  the 
82C54RH  timers  allows  a  maximum  delay  of  209.7  milliseconds.  If  the  watchdog  timer 
were  set  to  interrupt  ever\'  0.2  seconds  if  not  properly  reset,  this  would  allow  100.000 
processor  instructions  (assuming  10  clock  periods  per  instruction)  between  interruptions. 

If  required  by  an  on-board  experiment,  one  of  the  remaining  timers  could  be 
reconfigured  as  an  event  counter  or  programmable  pulse  generator.  This  would  have 
required  breaking  the  G.ATE  and  CLK  connections,  shown  in  Figure  10  on  page  36,  and 
reconnecting  these  as  required  by  the  experiment. 

The  82C54RH  inputs  A1  and  AO  determine  which  of  the  four  internal  registers 
is  selected  for  reading  or  writing.  As  in  previous  devices,  the  82C54RH  is  an  eight  bit 
device  connected  to  the  lower  half  of  the  data  bus.  Therefore,  BAl  and  BA2  are  used  to 
control  register  selection.  RD*  and  WR*  control  the  transfer  direction.  The  effect  of 
these  signals  is  shown  in  Table  II  on  page  48. 


Register  (action) 

Command 

Status 

Parameter 

Result 

(reset) 

TxINT  result 
(none) 

RxlN'T  result 
'fransmit  data 
Receive  data 


TxDACK- 
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Table  11.  82C54RH  REGISTER  SELECTION 


A1 

(BA2) 

AO 

(BAD 

Register 

0 

0 

counter  0 

0 

1 

counter  I 

1 

0 

counter  2 

1 

1 

control  word 

5.  Interrupt  controller 

Several  diHerent  levels  of  interrupt  control  have  been  identified.  However,  the 
80C86RH  has  only  two  interrupt  inputs,  N.VII  and  INT.  X.Ml  is  already  dedicated  to 
the  watchdog  timer.  To  manage  the  remaining  interrupts,  an  82C59RH  interrupt  con¬ 
troller  is  used.  The  interrupts  are  initially  prioritized  as  shown  in  Table  12  on  page  48, 
but  may  be  rotated  or  masked  by  the  programmer.  SP*  EN*  is  a  dual  function  pin.  As 
an  input,  it  designates  whether  the  82C59RH  is  a  slave  or  master.  It  can  also  be  used 
as  an  output  to  control  data  buffers.  In  this  implementation,  it  is  connected  to  Vdd  to 
program  the  82C59RH  as  a  master.  The  programmer  must  then  select  the  non-bufifered 
mode  in  initialization  command  word  four.  Programming  details  are  contained  in  Ref¬ 
erence  14,  pp.  3-133  to  3-146.  The  82C59RH  connections  are  shown  in  Figure  10  on 
page  36. 


Table  12.  82C59RH  INITIAL  INTERRUPT  PRIORITIES 


Priority 

Number 

Device 

Highest 

0 

unused 

1 

carrier  detect  (from  communications  package) 

2 

82C,54RH  timer  zero 

3 

8273  TxINT  (transmitter  interrupt) 

8273  R.XINT 


(receiver  interrupt) 


5  S2C54RH  timer  one 


6 

ICL71 15  HOC  (end  of  A'D  conversion) 

Lowest 

7 

8273  Flag  detect  (FLAGDET*) 

6.  I/O  device  chip  selection 

Five  devices  and  two  special  commands  have  been  mapped  to  the  PANSAT 
processor  1,  0  address  space.  The  highest  address  bit  used  by  these  devices  is  BA2.  This 
leaves  BA3  through  BA15  for  decoding  chip  select.  Chip  selection  can  be  easily  per¬ 
formed  by  a  54MC128  three  to  eight  line  decoder.  Address  lines  BA3  through  BA5  are 
used  for  chip  selection.  The  54HC13S  output  is  enabled  by  M,TO*  indicating  an  1  O 
space  transfer;  otherwise  the  decoder  outputs  are  disabled.  Address  bits  BA6  through 
BA  15  are  not  used  in  decoding.  This  implies  that  the  device  selection  repeats  every  64 
{40h)  addresses  up  to  the  maximum  address  of  65535h.  (For  example,  address  0042h  is 
the  same  as  0002h).  One  54HC138  output  is  unused,  allowing  addition  of  an  another 
peripheral  without  revising  1  O  device  chip  select  decoding.  The  1,  0  space  map  is  shown 
in  Figure  15  on  page  50.  Recommended  1  O  device  addresses  and  actions  are  summa¬ 
rized  in  Table  13  on  page  52. 

7.  I/O  device  timing  requirements 

.Although  most  of  the  peripheral  devices  selected  are  designed  to  work  specif¬ 
ically  with  the  80C86RH,  a  timing  analysis  must  be  performed  to  verify  that  all  read  and 
write  times  are  satisfied.  The  I,  O  write  cycle  will  be  analyzed  first.  The  80CS6RFI  pro¬ 
vides  a  340  nanosecond  (minimum)  write  pulse.  This  guarantees  at  least  a  352 
nanosecond  data  setup  time  before  WR*  goes  inactive.  The  peripheral  requirements  are 
shown  in  Table  14  on  page  50.  This  shows  that  no  wait  states  are  required  to  satisfy 
peripheral  write  timing  requirements.  The  resulting  system  peripheral  write  timing  is 
shown  in  Figure  16  on  page  51. 

A  preliminary  analysis  of  an  80C86RH  I,'0  read  cycle  shows  that  399 
nanoseconds  is  available  for  address  access,  364  nanoseconds  for  chip  select  access,  and 
179  nanoseconds  read  access  time.  Timing  for  this  cycle  is  shown  in  Figure  17  on  page 
54.  The  requirements  for  the  various  peripheral  devices  are  shown  in  Table  15  on  page 
53.  Several  devices  will  not  meet  the  minimum  guaranteed  read  access  time  in  all  cases. 
RD*  may  go  active  as  early  as  10  nanoseconds  into  T2,  but  as  late  as  165  nanoseconds. 
A  wait  state  must  be  inserted  to  satisfy  worst  case  timing. 

The  required  wait  state  can  be  generated  by  adjusting  the  inputs  to  the 
82C85RH  ready  signal  generator.  The  READY  input  to  the  80C86RH  must  be  disabled 
by  the  end  of  T2  (8  nanoseconds  into  T3)  to  guarantee  the  insertion  of  a  wait  state  [Ref. 
11  :  p.  A-23].  Two  ready  inputs  are  available  to  the  82C85RH  ready  generation  circuit. 
In  ASYNC  mode,  an  inactive  ready  input  causes  the  ready  output  to  go  inactive  at  the 
next  downward  clock  transition.  An  active  ready  input  is  first  synchronized  to  the  up- 
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Table  14.  PERIPHERAL  DEVICE  WRITE  TIMING  REQUIREMENTS 


Device 

3\'rite  pulse  width 

Data  setup  to  WR'-  inactive 

ICL7115 

100  nsec 

n  a 

8273 

250  nsec 

150  nsec 

8273 

TxDACK 

250  nsec 

150  nsec 

82C54RM 

240  nsec 

225  nsec 

82C55Rn 

loo  nsec 

100  nsec 

82C59R1I 

160  nsec 

160  nsec 

Table  13.  PANSAT  I/O  DEVICE  VALID  ADDRESSES 


Device 

Address 

Operand 

Action 

size 

HDLC 

(8273) 

OOh 

byte 

\VR*  =  0  command  register 

RD*  =  0  status  register 

02h 

byte 

VVR*  =  0  parameter  register 

RD*  =  0  result  register 

04h 

byte 

WR*  =  0  8273  reset 

RD*  =  0  TxINT  result 

06h 

byte 

WR*  =  0  (none) 

RD*  =  0  RxlNT  result 

28h 

byte 

transmit  data  register 

30h 

byte 

receive  data  register 

Parallel 

OSh 

byte 

port  A  (TLM  control) 

port 

(8255) 

O.Ah 

byte 

port  B 

OCh 

byte 

port  C  (device  control) 

OEh 

byte 

parallel  port  control  word 

Timer 

lOh 

counter  0 

(8254) 

12h 

byte 

counter  1 

14h 

byte 

counter  2  (watchdog  timer) 

16h 

byte 

timer  control  word 

A  D 

Converter 

18h 

byte 

WR*  =  0  initiate  conversion 

RD*  =  0  low  byte  of  result 

(ICL71 15) 

lAh 

byte 

RD*  =  0  high  byte  of  result 

ICh 

word 

both  bytes  of  result 

Interrupt 

20h 

byte 

command  register  0 

controller 

22h 

byte 

command  register  1 

ward  clock  transition,  then  the  READY  output  goes  active  at  the  next  downward  tran¬ 
sition,  meeting  the  minimum  80C86RH  setup  requirements.  The  ASYNC*  input  is 
connected  to  ground  to  select  ASYNC  mode.  One  82C85RH  ready  input  will  be  dedi¬ 
cated  to  memoiy  operations.  For  the  present,  RDYl  will  be  connected  to  .M,  10*.  The 
system  w  ill  normally  be  ready  if  memory'  operations  are  in  progress.  (This  assumption 
may  be  changed  during  memory’  system  design.)  How'ever,  this  signal  goes  inactive 
during  I  O  operations.  This  allow's  the  other  ready  input  to  control  ready  generation 
during  10  cycles.  The  second  input,  RDY2,  is  connected  to  the  output  of  a  54HC00 
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Table  15.  PERIPHERAL  DEVICE  READ  TIMING  REQUIREMENTS 


Device 

Address  access 
time 

Chip  enable  access 
time 

Read  active  access 
time 

1CL7115 

200  nsec 

200  nsec 

200  nsec 

8273 

300  nsec 

300  nsec 

300  nsec 

8273  RxDACK 

300  nsec 

n  a 

200  nsec 

82C54RH 

75  nsec* 

0  nsec* 

200  nsec 

S2C55RH 

0  nsec* 

200  nsec 

82C59RH 

210  nsec 

210  nsec 

160  nsec 

*  indicates  setup  time  before  RD*  goes  active 

NAND  gate  with  RD*  and  WR*  as  inputs.  See  Figure  10  on  page  36  for  connections. 
These  connections  result  in  a  wait  state  being  generated  if  RD*  or  WR*  is  not  active 
within  45  nanoseconds  after  the  start  of  T2.  (The  82C85RH  requires  a  55  nanosecond 
setup  time.  With  an  18  nanosecond  delay  through  the  54HC00  and  the  active  clock  edge 
occurring  at  118.6  nanoseconds,  this  leaves  45.6  nanoseconds  for  RD”^  or  WR"  to  go 
active  without  generating  a  wait  state.)  The  resulting  access  times  with  the  wait  state 
added  are  shown  in  Figure  18  on  page  55.  Figure  19  on  page  56  shows  the  resulting 
times  if  RD”^'  does  go  active  within  45  nanoseconds  of  the  start  of  T2. 

This  design  may  result  in  addition  of  wait  states  for  an  I  O  write  which  are  not 
needed.  However,  if  the  decision  to  insert  a  wait  state  is  delayed  until  RD*  or  WR*  go 
active,  then  the  82C55RH  minimum  setup  times  are  violated  and  the  required  wait  state 
may  not  be  generated.  The  simplicity  of  this  design  outweighs  this  occasional  slowing 
of  1  O  writes. 

G.  MEMORY  SYSTEM  DESIGN 

.Memor>^  design  is  affected  by  the  following  considerations: 

•  The  processor  must  be  able  to  independently  address  either  the  lower  byte  or  the 
upper  byte,  or  the  entire  1 6  bit  w^ord. 

•  The  lowest  locations  in  memory’  are  reserved  for  the  interrupt  vector  table. 

•  Program  execution  begins  at  location  FFFFOh  after  reset. 

•  Static  RAM  is  preferred  for  reliability  reasons  and  to  keep  the  design  simple. 

•  .Memory  circuits  may  be  located  on  a  separate  circuit  board;  connection  of  the 
memory  to  the  main  board  must  be  considered. 
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PANSAT  memory  is  to  be  divided  into  three  sections:  PROM,  vital  RAM,  and  bulk 
storage  RAM.  To  satisfy  the  above  requirements,  the  PROM  should  be  located  at  the 
top  of  memory  and  contain  the  restart  routine.  Likewise,  the  vital  R.AM  should  be  lo¬ 
cated  at  the  bottom  of  memory  to  hold  the  interrupt  vector  table.  (Since  the  watchdog 
timer  uses  the  non-maskable  interrupt,  this  pointer  is  considered  vital.) 

Memory  boards  can  be  connected  to  the  main  board  either  by  the  system  (multi¬ 
plexed)  data  bus,  or  the  separate,  demultiplexed  address  and  data  buses.  Using  the  sys¬ 
tem  bus  requires  each  memory  board  to  have  separate  address  latches  and  data 
transceivers.  While  this  prevents  failure  of  one  set  of  address  latches  from  causing  com¬ 
plete  system  failure,  the  overall  system  becomes  more  complex,  therefore  more  prone  to 
failure.  Additionally,  this  increases  the  required  output  drive  from  the  80C86RH.  For 
these  reasons,  using  the  demultiplexed  address  and  data  bus  to  connect  the  memory 
boards  is  preferred.  The  required  signals  are  BA0-BA19,  BD0-BD15,  RD*,  WR*,  BHE*, 
and  M  lO*. 

Design  is  also  constrained  by  available  technology  and  cost.  Although  one  megabit 
static  RAMs  have  just  been  announced  (by  at  least  one  vendor),  the  largest  commonly 
used  size  is  256  kilobit.  These  are  currently  available  in  high  reliability  versions.  Radi¬ 
ation  hardened  RAM  is  currently  more  limited,  being  available  in  64  kilobit  versions. 
As  technology  continues  to  advance,  higher  density  devices  will  become  available  in  ra¬ 
diation  hardened  versions.  This  presents  a  problem  in  memory  system  design.  Current 
device  availability  or  cost  constraints  may  not  apply  as  PANSAT  approaches  launch. 
Fnr  fliis  reason,  a  top  down  memoiy  decoding  .scheme  will  be  adopted  which  will  readily 
adapt  to  changing  availability  of  high  density,  radiation  hardened  R.-\.Ms  and  PROMs. 
The  specific  devices  that  are  actually  implemented  may  be  changed  due  to  cost,  avail¬ 
ability,  or  other  concerns  without  requiring  a  complete  redesign. 

PANSAT  memory  will  be  divided  into  64  kilobyte  sections  by  using  the  four  most 
significant  address  bits.  This  is  easily  accomplished  using  two  54HC138  three  to  eight 
line  decoders.  These  decoders  are  enabled  only  when  M  TO*  is  high.  This  is  accom¬ 
plished  by  connecting  M  TO’''  to  a  54HC04  inverter,  then  to  the  02”'  (active  low)  enable 
input.  (Only  one  active  high  enable  exists  on  the  54F1C138  and  two  are  needed.  Either 
M  lO’"  or  BA  19  could  be  inverted.  BA  19  already  has  an  additional  delay  through  the 
54HC573  addresses  latches,  therefore  inverting  M,TO*  adds  no  additional  delay.)  The 
lowest  section  will  be  reserved  for  vital  RAM.  The  highest  section  will  contain  the 
PROM.  Remaining  sections  will  contain  the  bulk  RAM.  This  approach  allows  flexibility 
to  change  devices  and  the  decoding  scheme  within  any  section  without  affecting  the 
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overall  design.  The  64  kilobyte  division  allows  two  32  kilobyte  by  eight  bit  (256  kilobit) 
static  R.AMs  to  be  used  in  each  section  without  further  decoding.  If  memories  larger 
than  256  kilobit  are  to  be  used  in  the  final  implementation,  the  memor}  system  must  be 
redesigned. 

Only  devices  which  are  known  to  be  currently  available  and  about  which  firm  data 
is  known  were  considered.  There  may  be  a  device  among  the  dozens  of  manufacturers 
that  would  be  better  than  those  chosen  but  this  design  will  be  shown  to  be  sufficient. 

The  requirement  to  address  low  byte,  high  byte,  or  both  implies  that  the  memor\' 
must  be  16  bits  wide.  Table  6  on  page  31  shows  how  selection  is  conditioned  on  AO  and 
BHE*.  This  implies  that  B.-XO  will  not  be  used  internal  to  the  memory  devices  for  byte 
selection.  BAl  is  the  least  significant  address  bit  used  internal  to  the  memories.  The 
distinction  between  low  and  high  byte  need  only  be  made  during  write  cycles.  During 
read,  the  processor  only  latches  the  byte  required  from  either  the  low  or  high  byte  of 
ADO-AD  15,  and  internally  routes  it  to  the  proper  register.  Write  of  even  addresses  must 
be  conditioned  on  AO  being  low.  W’rite  of  odd  addresses  must  be  conditioned  on  BHE* 
being  low. 

All  memor\'  device  output  enables  are  controlled  by  the  RD*  signal  generated  by  the 
processor.  This  helps  eliminate  data  bus  contention  between  memor>-  devices  on  con¬ 
secutive  memory  read  accesses. 

1.  Programmable  read  only  memory 

Two  2048  byte  C.MOS  6616RH  PROMs  will  be  used  for  permanent  program 
storage.  These  will  be  located  at  the  top  of  the  memory  address  space,  occupying  ad¬ 
dresses  FFOOOh  to  FFFFFh.  These  devices  are  a  radiation  hardened  version  of  the 
standard  6616  PROM.  This  device  is  also  synchronous,  but  the  synchronous  capability 
will  not  be  e.xploited  in  this  design.  The  device  will  be  connected  similar  to  an  asyn¬ 
chronous  memory  device;  its  access  times  are  sufficiently  fast  that  this  will  not  require 
addition  of  wait  states.  One  device  will  contain  even  addresses,  the  other  odd  addresses. 
To  meet  the  redundancy  discussed  earlier,  these  devices  will  be  duplicated.  A  circuit  us¬ 
ing  one  54F1C73  J-K  flip  flop  and  two  54HC32  OR  gates  will  be  used  to  select  one  of 
the  PROM  pairs.  The  J-K  flip  flop  is  connected  as  a  toggle  flip  flop  and  uses  RESET 
as  a  clock  pulse.  The  Q  and  Q*  outputs  alternately  enable  the  PROM  sets.  This  scheme 
relies  on  the  communication  system  to  provide  the  reset  input,  otherwise  another 
method  must  be  provided  to  select  the  active  PRO.M.  (Selection  must  not  presume  that 
the  processor  is  operating  properly.)  The  PROMs  are  read  only,  therefore  there  is  no 
need  to  differentiate  between  low  and  high  bytes.  The  top  64  kilobyte  section  must  be 
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divided  into  four  kilobyte  subsections  for  the  two  6616Rlls.  This  is  accomplished  b\  a 
second  54HC13S  which  uses  BA12-BA15  and  the  primary  541IC13S  output  as  inputs. 
The  circuitry  is  shown  in  Figure  20  on  page  60.  Figure  21  on  page  61  shows  the  result¬ 
ing  system  timing.  All  timing  requirements  arc  satisfied  with  no  wait  states. 

During  system  construction  and  test,  the  PRO.Vls  will  be  replaced  with 
EPROMs.  The  timing  for  these  devices  will  need  to  be  verified  when  they  are  specilied. 

The  redundant  capability  of  the  PROMs  is  not  matched  in  the  decoding  circui¬ 
try  that  selects  the  PROMs.  .At  a  slight  increase  of  complexity  the  decoding  circuitry  can 
be  made  redundant.  The  output  of  the  J-K  flip  flop  can  be  used  as  an  enable  input  for 
the  first  level  541IC13Ss.  The  Q  output  would  be  connected  to  one  54HC13S  G2B"  input 
with  the  Q*  output  connected  to  the  other  primary  5411C138.  Toggling  the  flip  flop 
would  alternately  select  the  two  decoding  circuits.  .An  additional  advantage  of  this  circuit 
is  that  the  IS  microsecond  delay  through  the  OR  gate  is  eliminated,  increasing  the  read 
cycle  margin.  This  modified  circuit  is  shown  in  Figure  22  on  page  62.  The  modified 
PRO.M  read  data  timing  analysis  is  shown  in  Figure  23  on  page  63.  The  simpler,  un¬ 
modified  circuit  is  used  in  system  power  analysis.  Specifications  for  the  6616RII  arc 
found  in  reference  6,  pp.  3-45  to  3-51.  .Additional  information  on  the  radiation  tolerance 
of  this  circuit  is  found  in  reference  6,  pp.  13-12  to  13-17. 

2.  Mtal  read/ssrite  memory 

Two  eight  kilobyte  CDM6264CD  3  static  R.AMs  are  used  for  vital  R.AM. 
These  devices  should  be  procured  in  the  radiation  hardened  version  to  meet  the  reliabil¬ 
ity  requirement  for  vital  RAM.  They  are  located  at  the  bottom  of  physical  memory  front 
address  OOOOOh  to  03FFFh.  The  bottom  64  kilobyte  section  must  be  subdivided  into  16 
kilobyte  sections.  1  his  is  accomplished  by  using  a  541 1C  139  two  to  four  line  decoder. 
This  decoder  uses  B.A14.  B.A15.  and  the  primary  541 1C  138  as  inputs.  The  circuitry  is 
shown  in  Figure  20  on  page  60.  Read  data  timing  is  shown  in  Figure  24  on  page  64. 
This  shows  that  critical  path  timing  {chip  enable  path)  is  satisfied  with  a  184  nanosecond 
margin  with  no  wait  states.  Write  data  timing  is  shown  in  Figure  25  on  page  65.  Critical 
path  timing  (data  setup  time)  is  satisfied  with  a  168  nanosecond  margin. 

.An  alternative  to  the  CDM6264CD  3  is  the  F1S-65C162R1 1  static  RAM.  This 
is  a  2048  word  device  available  in  a  radiation  hardened  version.  A  minimum  of  two  de¬ 
vices  would  be  required  to  implement  a  16  bit  memory.  The  secondary  decoder  must  be 
changed  to  a  541 1C  138  to  use  these  smaller  memories.  Specifications  for  this  device  are 
found  in  Reference  6,  pp.  3-29  to  3-32.  Device  specifications  for  the  CDM6264CD  3 
are  found  in  Reference  15  . 
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Figure  20.  PROM  and  vital  RAM 
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Figure  24.  Vital  RAM  read  data  timing  analysis 
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3.  Bulk  read/«rite  memory 

The  bulk  R.AM  will  be  implemented  in  CDM62256  32  kilobyte  static  RAMs. 
Sixteen  of  these  devices  will  provide  512  kilobytes  of  storage.  This  will  be  sufficient  for 
the  store  and  forward  message  buffer  or  for  holding  telemetry  or  experiment  data.  Two 
of  these  devices  will  be  used  in  each  64  kilobyte  section.  The  only  additional  decoding 
required  (beyond  the  top  level  54HC138)  is  selection  of  even  or  odd  byte  (or  both)  for 
a  write  cycle.  Bulk  RAM  will  occupy  memory  locations  lOOOOh  to  SFFFFh.  To  increase 
reliability,  this  RAM  will  be  divided  into  four  sections,  each  with  a  separate  54HC138 
decoder  and  write  conditioning  circuit.  The  circuitry  is  shown  in  Figure  26  on  page  67 
and  Figure  27  on  page  68.  The  read  data  timing  analysis  is  shown  in  Figure  28  on  page 

69.  This  shows  that  critical  path  timing  requirements  are  satisfied  with  a  119  nanosecond 
margin  and  no  wait  states.  The  write  data  timing  analysis  is  shown  in  Figure  29  on  page 

70.  This  shows  that  data  setup  times  are  satisfied  with  no  wait  states.  Specifications  for 
the  CD.M62256  are  found  in  reference  16. 

4.  Memory  summary 

This  design  provides  four  kilobytes  of  PRO.VI,  16  kilobytes  of  vital  RA.Vl,  and 
512  kilobytes  of  bulk  RA.M.  The  resulting  memory  address  map  is  shown  in  Figure  30 
on  page  71. 

H.  POWER  CONSUMPTION 

The  static  power  consumption  for  the  LSI  and  .MSI  circuits  is  shown  in  Table  16 
on  page  72.  This  does  not  include  the  dynamic  power  required  for  operating  circuits.  The 
address  latches  and  data  bus  transceivers  are  in  continuous  operation,  as  is  the  divide 
by  16  circuit  and  at  least  one  memory  decoder.  Operating  current  is  not  directly  avail¬ 
able  from  the  data  book.  However,  each  active  output  stage  can  be  assumed  to  source 
or  sink  20  microamps.  If  50  output  stages  are  assumed  to  be  instantaneously  operating, 
this  equates  to  one  milliamp.  The  total  current  draw  for  support  circuitiy  is  4.8 
milliamps.  Assuming  a  five  volt  supply  voltage,  the  power  required  is  24  milliwatts. 

Static  memory'  power  consumption  is  shown  in  Table  18  on  page  73.  Total  current 
required  is  2'^.44  milliamps,  or  102  milliwatts  at  five  volts.  Operating  power  is  spread 
over  the  entire  memory  array.  The  largest  operating  current  is  the  CDM62256.  Each 
CDM62256  requires  90  milliamps.  Assuming  word  operations,  this  is  180  milliamps,  or 
900  milliwatts.  Total  current  required  for  memory  operations  is  200  milliamps,  or  one 
watt. 
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Figure  27.  Bulk  RAM  (Addresses  50000li  to  8FFFFI1) 
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RD«.  OT/R»,  M/IO* 


FFFFFh 

PROM  (6616RH) 

FFeOOh 

FEFFFh 

eFFFFh 

BULK  RAM  (CDM622S6> 

ledOOh 

0FFFFH 

eaFFFh 

UITAL  RAM  <CDM6264) 

doeoeh 

Figure  30.  PANSAT  memory  address  map 


The  80C86RH  and  associated  LSI  circuit  power  consumption  is  shown  in  Table  17 
on  page  72.  A  total  current  of  284  milliamps  is  required,  or  1.42  watts  at  five  volts. 

The  above  power  estimates  use  the  military  temperature  rating  (-55°C  to 
4- 125  °C).  Total  current  required  is  estimated  at  488  milliamps  equating  to  2.44  watts 
at  five  volts.  This  may  be  a  little  high  for  continuous  operation  powered  only  by  a  small 
solar  cell  array.  If  the  HDLC  power  is  secured  and  the  processor  executes  a  HALT  in¬ 
struction,  waiting  for  a  timer  interrupt  to  restart  operation,  the  required  current  can  be 
reduced  by  at  least  400  milliamps.  This  will  reduce  power  consumption  below  390  milli¬ 
watts.  Securing  just  the  HDLC  will  reduce  the  current  by  180  milliamps,  reducing  the 
power  consumed  to  1.54  watts. 

Table  2  on  page  11  shows  processor  power  consumption  for  the  UoSAT-2  and 
FO-12.  PANSAT  power  consumption  of  2.54  watts  lies  between  the  FO-12  requirement 
of  3.5  watts  and  the  UoSAT-2  usage  of  one  watt.  The  capability  of  PANSAT  is  greater 
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than  that  of  L'oSAT-2  but  less  than  that  of  FO-12.  This  indicates  that  power  consump¬ 
tion  is  appropriate  for  the  capability  of  the  satellite. 


Table  16.  LSI  AND  MSI  CIRCUIT  STATIC  POWER  CONSUMPTION 


Device 

Current  per  device 
iiu  amps) 

Number  of  devices 

Total  current 
(i/  ampsi 

54HC00 

40 

1 

40 

54HC04 

40 

5 

200 

54HC32 

40 

3 

120 

54HC73 

80 

1 

80 

54HC13S 

160 

9 

1440 

54HC139 

160 

1 

160 

54HC161 

160 

1 

160 

54HC245 

160 

2 

320 

160 

3 

480 

54HC40I6 

40 

2 

SO 

54HC4051 

160 

5 

800 

Total: 

3880 

Table  17.  LSI  POWER  CONSUMPTION 


Device 

Operating  current  (milliamps)  at 

5  MHz 

80CS6RH 

50 

82C85RH 

30 

82C54RH 

10 

82C.89RM 

5 

82C55RH 

output  drive  (up  to  3) 

1CL7115 

6 

8273 

180 

Total: 

284 

I.  COMMENTS  ON  THE  DESIGN 

To  properly  survive  in  the  space  environment,  all  circuits  must  meet  militarv’  tem¬ 
perature  range  specifications.  Additionally,  they  should  be  procured  in  hermetically 
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Table  18.  MEMORY  DEVICE  POWER  CONSllMPTlON 


Device 

Standby 

current 

(milliamps) 

Number  of 
devices 

l  ota!  standby 

current 

(milliamps) 

Operating 
current 
( milliamps) 

RO.M 

(6616RH) 

0.1 10 

4 

0.440 

Vital  R.AM 
(CD\I6264) 

2.0 

4.0 

15 

Bulk  R.A.\1 
( CD  M  62256) 

1.0 

16 

16.0 

40 

Total 

20.44 

scaled,  side  brazed  packages.  This  is  in  addition  to  the  radiation  hardened  or  high  reli¬ 
ability  specifications  mentioned  above. 

No  additional  drive  has  been  added  to  RD*.  WR*.  or  .\1  lO.  Additional  drive  on 
these  control  signals  docs  not  appear  to  be  necessar\'.  This  assumption  may  need  to  be 
changed  if  testing  shows  additional  drive  is  needed.  Sufficient  margin  e.xis'^  in  all  read 
and  write  tintings  for  the  additional  delays  that  would  be  imposed. 

The  design  has  been  kept  simple  both  to  keep  power  consumption  low  and  to  reduce 
the  probability  of  failure  from  comple.xity.  Fairly  generous  Mining  margins  have  been 
enforced  to  ensure  data  is  transferred  reliably. 

The  din'erentiation  between  vital  and  non-vital  ICAM  may  be  fairly  artificial,  espe¬ 
cially  if  all  R.\.M  is  implemented  with  the  same  devices.  A  more  elegant  solution  might 
delete  this  distinction.  Several  independently  decoded  sections  of  ICAM  could  be  pro¬ 
vided.  On  reset,  the  kernel  would  test  all  sections  and  mark  sections  that  fail  as  una¬ 
vailable.  This  would  increase  the  comnlexity  of  the  kernel  that  must  be  present  in  RO.\I. 
.Additionally,  programs  uploaded  must  be  dynamically  relocatable  as  any  section  of 
memorx  can  be  presumed  to  be  unavailable.  However,  system  operation  would  still  be 
affected  if  low  memory  containing  the  interrupt  table  were  unavailable.  Even  this  Uini- 
culty  could  be  avoided  if  some  form  of  dynamic  decoding  were  available.  .After  identify¬ 
ing  usable  memor  y,  the  processor  configures  memor>  so  that  one  of  the  usable  sections 
occupies  lov.'  memory.  One  possible  dynamic  decoding  circuit  is  shown  in  Figure  31  on 
page  74.  This  prosides  eight  ncisiblc  mappings  of  eight  64  kilobyte  memory  sections  into 
the  lov  512  kilobytes  of  memoiy.  This  circuit  adds  a  24  nanosecond  delay  to  decoding 
(through  the  l.XOR  gate).  .Any  single  failed  section  of  memory  can  be  moved  to  the 


highest  address  (within  the  512  kilobyte  space).  This  and  other  enhancements  to 
PANSAT  memory  reliability  provide  areas  for  further  study. 

This  design  did  not  explicitly  piovide  a  capability  to  expand  into  a  distributed 
processing  network  for  more  complicated  systems  such  as  ORION.  1  his  capability  can 
be  added  by  adding  an  additional  82C55RH  parallel  port  to  the  unused  section  of  1,0 
space.  This  parallel  port  can  be  configured  for  bi-directional,  parallel  data  transfers  to 
two  other  processors.  Thus,  a  ring  network  of  processors  could  be  established.  This 
capability  is  not  required  for  PANSAT  and  will  not  be  examined  further. 


MJUSTABUe 

OeCOOER 


Figure  31.  Dynamic  memory  decoding  circuit  and  resulting  mappings 


IV.  RELIABILITY  ANALYSIS 


PANSAT  is  a  relatively  simple  satellite.  It  is  not  stabilized  and  has  neither  a  transfer 
rocket  motor  nor  attitude  control  thrusters.  Therefore  a  processor  error  cannot  cause  the 
satellite  to  de-orbit  prematurely  or  directly  endanger  human  life.  It  cannot  cause  an  error 
in  antenna  pointing  that  would  prevent  communications  with  the  satellite.  A  tspical 
processor  error  will  cause  experiment  data  to  be  lost  or  a  message  to  become  garbled. 
The  most  impact  a  processor  failure  could  have  would  be  one  that  caused  the  transmitter 
to  remain  continuously  keyed.  This  could  disrupt  communications  on  the  frequency  used 
by  the  satellite.  (This  may  be  self  correcting,  as  continuous  transmission  may  require 
more  power  than  can  be  supplied  by  the  solar  cells.)  .-\t  worst,  complete  failure  will 
cause  a  mission  failure.  Presuming  the  reset  system  works  through  the  communications 
link,  the  processor  can  be  reinitialized  after  an  error  causes  a  program  abort.  The  re¬ 
quirement  is  to  keep  the  error  rate  low  enough  that  useful  work  can  be  accomplished 
between  system  errors. 

Because  of  the  small  size  and  low  (relative  to  typical  satellite  projects)  cost  of 
P.ANSAT,  n-module  redundancy  and  voting  techniques  are  not  appropriate.  These 
would  increase  complexity,  size,  and  power  consumption  beyond  the  capability  of  the 
satellite.  .Additionally,  the  increased  complexity  may  of  itself  cause  failures. 

Presuining  the  hardware  is  operating  correctly,  the  burden  for  reliable  operation  falls 
to  the  software.  An  initial  list  of  software  requirements  is  listed  in  the  appendix. 

The  design  of  PANS.AT  has  centered  on  several  reliability  concepts.  These  are,  fault 
avoidance,  fault  detection,  and  fault  tolerant  features. 

A.  FAULT  AVOIDANCE 

Fault  avoidance  features  minimize  the  possibility  of  fault  occurrence.  PANS.AT  has 
two  major  fault  avoidance  features.  First,  system  timing  has  been  analyzed  to  ensure 
that  all  data  transfers  will  occur  reliably.  As  the  components  age  and  are  exposed  to 
radiation,  tinting  margins  may  be  reduced.  Leaving  at  least  50  nanoseconds  margin  on 
all  critical  paths  will  help  minimize  errors  caused  by  the  effects.  Second,  the  system  de¬ 
sign  has  been  kept  si.mple  overall.  No  exotic  circuits  or  methods  are  used.  Every  effort 
has  been  made  to  eliminate  bus  contention.  The  following  items  also  contribute  to  fault 
avoidance: 


•  The  processor  and  associated  LSI  circuitry  (except  IIDLC  and  A  D  converter)  are 
available  in  radiation  hardened  versions. 

•  All  SSI  and  MSI  components  are  available  in  high-reliability  versions.  (Radiation 
hardened  versions  of  these  circuits  are  also  available  if  required.) 

•  PRO.M  and  vital  R„‘\.VI  is  implemented  in  radiation  hardened  devices. 

•  Bulk  R.AM  is  available  in  high-reliability  versions. 

B.  FAULT  DETECTION 

The  major  fault  detection  feature  is  the  watchdog  timer.  The  watchdog  timer  is 
implemented  to  reset  the  processor  if  a  failure  has  caused  the  processor  to  HALT,  enter 
an  infinite  loop,  or  otherwise  suspend  normal  program  execution.  A  correctly  operating 
processor  will  reset  the  watchdog  periodically.  If  the  processor  does  not  reset  the 
watchdog,  the  non-maskable  interrupt  will  reinitialize  the  processor  when  the  timer 
count  expires.  This  feature  is  dependent  on  proper  software  implementation  for  opera¬ 
tion. 


C.  FAULT  TOLERANCE 

Two  major  features  have  been  included  in  the  design  to  allow  the  processor  to  con¬ 
tinue  operation  if  a  circuit  or  device  fails  First,  two  redundant  sections  of  PROM  are 
provided.  The  reset  line  toggles  PROM  selection.  Corruption  of  the  program  stored  in 
one  PROM  will  still  allow  correct  initialization  from  the  alternate  PROM  on  the  next 
reset.  The  second  fault  tolerant  feature  is  the  four  redundant  memory  sections.  Failure 
of  one  section  will  not  affect  the  remaining  sections.  In  addition,  this  redundancy  could 
be  extended  to  the  vital  R,AM  by  using  an  adjustable  decoding  scheme. 

D.  FAILURE  MODES 

There  are  several  single  point  failure  items  in  this  system.  Failure  of  any  of  the  fol¬ 
lowing  will  cause  complete  system  failure: 

•  80CS6RH  processor 

•  82CS5  clock  generator  (and  clock  crystal) 

•  82C59RH  interrupt  controller 

•  54HC245  data  bus  transceivers 

•  54HC573  address  latches 

•  peripheral  device  chip  select  (54HC138) 

•  8273  HDLC  controller 
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With  the  exception  of  the  8273,  all  these  devices  are  available  in  radiation-hardened  or 
high-reliability  version";.  The  S0CS6RH  exhibits  a  failure  rate  of  0.U03S3  percent  per 
thousand  hours  (Ref  6:  p.  9-5].  (This  and  all  following  rates  arc  at  +55°C.)  7'hc  re¬ 
maining  54HC  type  circuits  exhibit  a  failure  rate  of  0.0004  percent  per  thousand  hours 
[Ref  15:  p.  70].  (These  figures  are  for  the  CD54HC  version.)  Failure  rates  for  the  8273 
are  not  specified  in  Reference  13.  However,  this  circuit  approaches  the  80C86  in  com¬ 
plexity.  The  standard  (not  radiation  hardened)  version  of  the  80C86  exhibits  a  failure 
rate  of  0.025  percent  per  thousand  hours.  If  the  8273  failure  rate  were  five  times  worse 
than  the  80C86,  this  would  equate  to  0.125  percent  failures  per  thousand  hours.  During 
the  13,100  hour  mission  of  PANS.^T,  this  would  be  a  1.637  percent  probability  of  fail¬ 
ure.  (A  factor  of  five  was  used  to  account  for  the  increased  stress  of  orbital  environ¬ 
ment.)  The  8273  is  then  the  single  item  most  likely  to  cause  mission  failure.  Although 
an  extensive  fault  tree  analysis  vvas  not  conducted,  a  first  order  estimate  based  on  the 
8273  reliability  indicates  that  the  design  will  have  approximately  98  percent  probability 
of  completing  the  required  lifetime. 

Several  other  devices  could  cause  partial  mission  failure  if  they  malfunction.  These 
are: 

•  82C54  timer 

•  541 1C  161  divide  by  16  circuit 

•  1CL71 15  A  D  converter 

•  82C55RH  parallel  port 

Failure  of  these  devices  will  not  prevent  communication  with  the  satellite  or  can  be 
worked  around  to  restore  the  function.  For  example,  failure  of  the  1CL7115  A  D  con¬ 
verter  will  not  directly  preclude  communication  with  the  satellite,  thereby  causing 
mission  failure.  (There  may  be  an  indirectly  cause,  such  as  this  failure  causing  the  power 
monitoring  circuit  to  incorrectly  charge  the  batteries.)  The  54HC161  will  impact  both 
the  ICL71I5  and  the  timer  if  it  fails.  The  54HC161  may  therefore  be  a  candidate  for 
duplication. 

Within  the  allowable  complexity,  cost,  and  power  budget,  the  processor  design  pre¬ 
sented  is  sufficiently  reliable.  Verification  of  reliable  design  depends  upon  actual  opera¬ 
tion.  Increasing  HDLC  reliability  to  increase  overall  design  reliability  is  an  area  for 
further  study. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 

The  PANSAT  definition  depends  on  a  ground  station  that  can  communicate  in  the 
AX. 25  format.  At  present,  NPS  does  not  have  such  a  communication  capability.  Ground 
station  development  and  testing  need  not  wait  on  PANSAT.  The  ground  station  should 
be  up  and  operating  with  current  amateur  satellites,  such  as  the  FO-12.  to  provide  a 
proven  ground  station  before  launch  of  PANSAT.  Therefore,  the  construction  of  an 
amateur  satellite  ground  station  that  communicates  in  the  AX. 25  format  should  be 
undertaken. 

.Maintaining  acceptable  throughput  on  the  store  and  forward  link  requires  a  low  bit 
error  rate.  P.\NS.-\T  is  unstabilized  and  therefore  must  use  omni-dircctional  receive  and 
transmit  antennas.  PANS.AT  also  has  only  relatively  low  power  available  from  the  solar 
cell  array.  Both  of  these  limitations  will  have  a  negative  impact  on  the  communications 
power  budget,  and  therefore,  on  the  bit  error  rate.  The  communications  package  must 
be  carefully  designed  to  maintain  acceptable  bit  error  rates  under  these  constraints. 

The  functions  of  PANS.AT  have  been  e.xamined  and  computing  requirements  for 
these  functions  determ  ned.  A  design  has  been  specified  that  meets  these  requirements. 
This  design  included: 

•  Four  kilobytes  of  radiation  hardened  PRO.M, 

•  16  kilobytes  of  radiation  hardened,  vital  R.-\M, 

•  512  kilobytes  -^f  high  reliability,  non-vital  RA.Vl,  divided  into  four  independent 
sections. 

•  seven  analog  control  channels  (expandable  to  15)  for  power  system  and  e.xperiment 
control, 

•  36  telemetry  input  channels  (expandable  to  64)  with  a  14  bit  A,  D  converter  for 
telemetry  -'ollection, 

•  a  hardware  HDLC  protocol  implementation  for  the  communication  system,  and 

•  e.xpansion  capability  to  meet  future  ORION  distributed  processing  needs. 

Although  every  eflbrt  has  been  made  to  ensure  this  design  is  correct,  it  is  in  essence  a 
paper  design  and  as  such  is  subject  to  limitations.  Implementation  of  the  design  and 
proving  its  effectiveness  remain  as  follow-on  thesis  topics.  Due  to  unknown  specifics 
about  other  satellite  subsystems,  several  items  have  been  incompletely  specified.  These 
are: 
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•  Reset  interface  to  conmiunications  system. 

•  HDLC  interface  to  communications  system. 

•  RC  value  for  Schmidt  trigger  reset  input  (depends  on  power  system  specifics). 

•  Interface  to  get-away  special  canister  while  on  board  the  shuttle. 

•  15  .MHz  ciy  stal  load  capacitance  (depends  on  specific  crv'stal). 

•  Power  and  experiment  control. 

•  Telemetrx'  specifics  (including  whether  the  A  D  precision  desired  will  require  op- 
amps  to  maintain  input  signal  levels). 

While  many  questions  remain  to  be  answ'ered,  it  is  hoped  that  this  first  design  attempt 
on  PANS.-XT  will  serve  as  a  launching  point  for  the  additional  work  required  to  bring 
up  PANSAT  as  a  viable  system. 
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APPENDIX  SOFTWARE  REQUIREMENTS 

This  is  a  partial  list  of  requirements  placed  on  the  software  by  the  particular  hard¬ 
ware  configuration.  There  are  two  possible  implementations  for  loading  the  software. 
The  kernel  may  be  completely  contained  in  the  PROM.  Alternatively,  only  a  loader  is 
contained  in  the  PROM.  This  loader  will  perform  the  initial  configuration  on  reset,  then 
prepare  the  processor  to  receive  the  kernel  via  the  communications  link.  This  is  shown 
below  as  loader  initialization  and  system  initialization.  If  the  entire  program  can  be  held 
in  PROM,  these  steps  should  be  combined. 

A.  LOADER  INITIALIZATION 

A  jump  to  the  initialization  service  routine  must  be  located  at  address  FFFFOh 
(within  the  PROM).  This  loader  routine  must: 

•  Configure  the  80C55RH  for  mode  0  output  and  set  initial  device  status  through 
port  C. 

•  Set  the  8273  (HDLC)  operating  mode. 

•  Set  the  80C59RH  (interrupt  controller)  operating  mode  and  initialize  interrupt 
numbers  for  CD*,  RxINT.  and  T.xINT. 

•  Set  interrupt  vectors  for  CD*.  RxINT,  and  TxINT  in  the  interrupt  vector  table. 

The  initialization  routine  will  then  wait  for  the  store  and  forward  program  to  be  up¬ 
loaded.  A  variation  would  not  initially  power  up  the  8273,  but  use  the  CD*  interrupt  as 
a  signal  to  activate  and  program  the  8273.  then  receive  the  program.  In  addition,  security 
is  required  to  ensure  that  only  an  authorized  ground  station  can  upload  the  initial  pro¬ 
gram. 

B.  KERNEL  INITIALIZATION 

The  kernel  must  perform  the  following  initializations  when  it  is  uploaded: 

•  Store  interrupt  vectors  for  NMI  (watchdog)  and  seven  82C59RH  interrupts. 

•  Set  82C59RH  operating  mode,  initialize  interrupt  vector  numbers,  and  unmask  re¬ 
quired  interrupts. 

•  Set  watchdog  timer  mode  and  start  timer. 

The  kernel  may  then  begin  normal  operations. 
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C.  REAL  TIME  KERNEL 

The  real  time  kernel  performs  the  following  functions: 

•  power  management 

•  manage  the  store  and  forward  message  system,  including  scheduling  transmissions 
and  managing  the  message  buffer. 

•  schedule  telemetry  collection 

•  routinely  reset  the  watchdog  timer  (this  must  not  occur  inside  an  interrupt  routine 
or  it  will  not  catch  system  malfunctions) 

•  provide  security  tor  commands  so  only  authorized  ground  stations  can  execute 
commands  or  upload  revised  programming 

•  receive  and  execute  commands 

D.  INTERRUPTS 

Several  interrupts  are  assigned  to  specific  events.  The  two  82C54RH  timer  interrupts 
may  be  used  by  the  programmer  to  schedule  events.  Dedicated  interrupts  are: 

•  TxINT:  provide  next  byte  of  transmit  data  to  the  8273 

•  RxIXT:  read  next  byte  of  received  data  from  8273 

•  EOC:  read  conversion  result  from  ICL7115 

•  CD:  configure  8273  to  receive  data  (This  interrupt  should  be  masked  if  the  8273 
already  has  power  and  is  configured  for  operation.) 

The  8273  FL.AGDET*  interrupt  may  be  used  as  needed  by  the  software  designer. 
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